Здравствуйте, koodeer, Вы писали:
K>В меньшем количестве кода легче разобраться. Даже без документации.
Это если ты область исходил и решал типовые задачи раз сто вдоль и поперек, то так и будет.
K>А с учётом того, что разрабу приходится писать меньше кода, у него останется больше времени, что может сподвигнуть на создание документации.
Основное время у разраба уходит не на кодинг, если конечно он код не под диктовку пишет
K>Насчёт семантики сложно сказать. По идее, она соответствует предметной области. Если человек владеет ей (а он обязан ей владеть, если уж стал писать код), то легко поймёт DSL.
А если не владеет, то библиотеку понять в разы проще. Что собтсвенно типичный случай — приходит девелопер на новый проект и постепенно осваивает все что надо.
Re[9]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Предлагаю разобраться в «коротком коде, который понятен без документации» тех же LINQ'а и SQL'я или любого другого DSLя
Гыгы, кстати +100.
(мечтательно) С кучей вложенных запросов...
Re[10]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Предлагаю разобраться в «коротком коде, который понятен без документации» тех же LINQ'а и SQL'я или любого другого DSLя
D>Гыгы, кстати +100. D>(мечтательно) С кучей вложенных запросов...
Кстати, я так предполагаю, что куча народа до сих пор думает, что LINQ только для баз данных, хотя известно, что он для коллекций в целом. Только вот как эти коллекции писать...
У нас тут есть DSL, который и жнец и швец и на дуде игрец. Краткое *неполное*, с большим количеством TODO: add description и быстро устаревающее описание занимало страниц десять
Правда, в итоге человека заставили написать вполне приличное описание, провести четыре (!) обзорных и одну техническую презентацию внутри компании и полностью задокументировать код, потмоу что он объявил о своих планах уйти, и он был единственным, кто понимал, как эта хрень работает
Здравствуйте, Mamut, Вы писали:
M>Правда, в итоге человека заставили написать вполне приличное описание, провести четыре (!) обзорных и одну техническую презентацию внутри компании и полностью задокументировать код, потмоу что он объявил о своих планах уйти, и он был единственным, кто понимал, как эта хрень работает
Молодой, неопытный...
Re[7]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Я об этом и говорю. Никакого «обычно» не будет. Он будет документирован не лучше и не хуже, чем любой другой код. Хотя, учитывая, что это будет domain-specific language, то будет документирован еще хуже, так как в условиях «о, у нас домен, давай колбасить DSL» никто не будет выписывать весь синтаксис, семантику и т.п.
Непонятно о чем мы спорим тогда. Люди часто не документируют код. При этом иногда получается грамотный и читабельный код, который легко поддерживать, а иногда макаронный и нечитабельный. Это ортогонально тому, DSL они пишут или библиотеку.
Когда ты читаешь код a.Insert(b) и insert b into a у тебя примерно одинаково информации, для понимания того, что происходит. Но в первом случае тебе надо знать соглашения, чтобы понять, что происходит, а во втором не нужно.
DSL от аналогичной библиотеки отличается только тем, что у них разные синтаксисы. Но тот или другой все равно придется учить. И в каких-то предметных областях DSL получается проще чем родной синтаксис языка.
К примеру, в ruby уже невозможно провести черту между DSL и обычным API. Можно, например, сказать, что рельсы это DSL для веб разработки. А можно, что это всего лишь набор из нескольких слабо связанных библиотек, каждая из которых выполняет свою функцию.
Мой основной поинт в этой дискуссии как раз в том, что не надо проводить границы и утверждать, что DSL априори лучше или хуже. Это такая же практика, как и любая другая. Не надо ее идеализировать или демонизировать. Будущее программирования в том, что мы перестанем различать DSL как отдельную технику, она станет просто рутинной.
M>>Я об этом и говорю. Никакого «обычно» не будет. Он будет документирован не лучше и не хуже, чем любой другой код. Хотя, учитывая, что это будет domain-specific language, то будет документирован еще хуже, так как в условиях «о, у нас домен, давай колбасить DSL» никто не будет выписывать весь синтаксис, семантику и т.п.
Z>Непонятно о чем мы спорим тогда.
M>>Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.
Z>Обычно документированный.
С какого перепугу?
Z> Люди часто не документируют код. При этом иногда получается грамотный и читабельный код, который легко поддерживать, а иногда макаронный и нечитабельный. Это ортогонально тому, DSL они пишут или библиотеку.
Z>Когда ты читаешь код a.Insert(b) и insert b into a у тебя примерно одинаково информации, для понимания того, что происходит. Но в первом случае тебе надо знать соглашения, чтобы понять, что происходит, а во втором не нужно.
Да, безусловно, ведь всегда удобно привести уже не один десяток лет существующий, успешный, стандартизированный DSL, да еще построенный поверх мат. модели, и сказать — вот! Он понятен без соглашений!
Хотя понятно, что можно привести совершенно противоположныей пример. и даже в твоем insert into возникает толпа вопросов: что возврашает этот код? Что произойдет, если b уже существует в a и т.п.
Z>DSL от аналогичной библиотеки отличается только тем, что у них разные синтаксисы. Но тот или другой все равно придется учить. И в каких-то предметных областях DSL получается проще чем родной синтаксис языка.
Ключевое: каких-то. Ключевое: надо учить. Ключевое: документация Если DSL-и начнут клпеать все, кому не лень, сказки про «DSL обычно документирован» можно пешим строем отправлять в детский сад. Хотя, по большому счету, их надо туда отправлять уже сейчас.
И никакое «ах, там кода короче и он иногда понятней» это не компенсирует.
Z>К примеру, в ruby уже невозможно провести черту между DSL и обычным API. Можно, например, сказать, что рельсы это DSL для веб разработки. А можно, что это всего лишь набор из нескольких слабо связанных библиотек, каждая из которых выполняет свою функцию.
Безусловно. И, как любая библиотека, она требует изучения и документации. Никакого «обычно документирован» там нет и не прдевидится.
Z>Мой основной поинт в этой дискуссии как раз в том, что не надо проводить границы и утверждать, что DSL априори лучше или хуже. Это такая же практика, как и любая другая. Не надо ее идеализировать или демонизировать. Будущее программирования в том, что мы перестанем различать DSL как отдельную технику, она станет просто рутинной.
Здравствуйте, Ziaw, Вы писали:
Z>Когда ты читаешь код a.Insert(b) и insert b into a у тебя примерно одинаково информации, для понимания того, что происходит. Но в первом случае тебе надо знать соглашения, чтобы понять, что происходит, а во втором не нужно.
Наоборот: в первом случае ничего не надо знать, т.к. это стандартный синтаксис вызова метода. В крайнем случае можно Ctrl+Click по имени метода и попадаем в его определение. А во втором случае — вообще непонятно кто это писал, как оно работает, и куда надо идти чтобы найти концы. То, что это выглядит как осмысленная фраза на естественном языке, не даёт никаких преимуществ, скорее наоборот, т.к.:
1. Может быть, там какой-нибудь бред в духе #define true false в реализации, переворачивающий весь этот "естественный язык" с ног на голову.
2. Я же не могу, прочитав эту естественную и возрадовавшись, начать писать вообще весь код в свободном стиле: "store sum of a and b to c".
M>>>В C++ функция printf это DSL или нет ? спасибо.
M>>В С++ скорее cout/cin — это DSL.
M>Своих синтаксических контсрукций они не вводят , все в пределах языка. А printf вводит.
DSL не обязательно вводит новые синтаксические конструкции. А в printf конструкции форматирования вполне могут считаться DSL'ем, имхо.
Давай я уточню свою позицию, "DSL обычно документированы" относится только к нормальным DSL готовым к использованию.
Я не рассматриваю DSL которые могут быть созданы по желанию левой пятки не пойми кого. Этот не пойми кто сейчас создает говнокод, который не лучше и не хуже гипотетического DSL, но нам-то этого какая беда и зачем мы вообще об этом говорим?
Если у тебя доводы в пользу того, что DSL намного сложнее документировать и это является значимой проблемой DSL ты приводи доводы а не цепляйся к словам.
M>Хотя понятно, что можно привести совершенно противоположныей пример. и даже в твоем insert into возникает толпа вопросов: что возврашает этот код? Что произойдет, если b уже существует в a и т.п.
Это контр-пример? Что возвращает Insert? Что произойдет если b уже существует в а?
Z>>DSL от аналогичной библиотеки отличается только тем, что у них разные синтаксисы. Но тот или другой все равно придется учить. И в каких-то предметных областях DSL получается проще чем родной синтаксис языка.
M>Ключевое: каких-то. Ключевое: надо учить. Ключевое: документация Если DSL-и начнут клпеать все, кому не лень, сказки про «DSL обычно документирован» можно пешим строем отправлять в детский сад. Хотя, по большому счету, их надо туда отправлять уже сейчас.
А зачем тебе юзать DSL который клепают все кому не лень и зачем мы это обсуждаем? Иерархии классов клепают все кому не лень, документируют обычно никак, ООП на помоечку что ли?
Z>>К примеру, в ruby уже невозможно провести черту между DSL и обычным API. Можно, например, сказать, что рельсы это DSL для веб разработки. А можно, что это всего лишь набор из нескольких слабо связанных библиотек, каждая из которых выполняет свою функцию.
M>Безусловно. И, как любая библиотека, она требует изучения и документации. Никакого «обычно документирован» там нет и не прдевидится.
Рельсы плохо документированы? Где примеры плохих DSL? Ок, давай выкинем из спора DSL и начнем спорить о том, документированы ли обычно библиотеки. Примерно эту тему ты до сих пор пытаешься развить.
M>Я вообще не про это говорил, если что.
О чем ты говорил? О том, что миллионы индусов наклепают тонны недокументированных DSL и наступит ад? Почему ты до сих пор можешь работать, хотя они наклепали тонну аналогичных библиотек?
Re[9]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, dimgel, Вы писали:
D>Наоборот: в первом случае ничего не надо знать, т.к. это стандартный синтаксис вызова метода. В крайнем случае можно Ctrl+Click по имени метода и попадаем в его определение.
В общем случае не попадаем, мы ведь не знаем точно тип a. Я правильно понимаю, что основная претензия к DSL свелась к отсутствию поддержки Ctrl-Click?
D>А во втором случае — вообще непонятно кто это писал, как оно работает, и куда надо идти чтобы найти концы. То, что это выглядит как осмысленная фраза на естественном языке, не даёт никаких преимуществ, скорее наоборот, т.к.:
Прикол в том, что в первом точно так же непонятно кто это писал и как оно работает. Сейчас вы с Мамутом успешно сводите проблему DSL к проблемам навигации. Которые были и до сих пор есть в C++, например, но решены в более современных языках.
D>1. Может быть, там какой-нибудь бред в духе #define true false в реализации, переворачивающий весь этот "естественный язык" с ног на голову.
Если начинать говорить про бред могу рассказать, как сделать, чтобы метод Insert начал очищать список. Но ты ведь и сам это прекрасно знаешь, зачем приводить такие аргументы?
D>2. Я же не могу, прочитав эту естественную и возрадовавшись, начать писать вообще весь код в свободном стиле: "store sum of a and b to c".
Конечно не можешь. Точно так же не можешь начать писать a.MakeTheUniverseWorkForMe(), узнав синтаксис вызова метода и не затрудняя себя изучением контракта a.
Re[10]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>О чем ты говорил? О том, что миллионы индусов наклепают тонны недокументированных DSL и наступит ад? Почему ты до сих пор можешь работать, хотя они наклепали тонну аналогичных библиотек?
Когда имеешь дело с библиотекой, надо выяснить только семантику методов. Когда с DSL — надо еще и синтаксис ковырять. Очевидно, что писать совсем простой DSL не имеет смысла. А немаленький DSL надо, во-первых, проектировать (что уже само по себе сложно), во-вторых он по любому будет содержать "темные углы". В придачу к темным углам языка добавляются темные углы DSL.
В общем, DSL нужен только когда без него вообще не обойтись. И это надо в каждом конкретном случае показать.
Re[11]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
ARK>Когда имеешь дело с библиотекой, надо выяснить только семантику методов. Когда с DSL — надо еще и синтаксис ковырять. Очевидно, что писать совсем простой DSL не имеет смысла. А немаленький DSL надо, во-первых, проектировать (что уже само по себе сложно), во-вторых он по любому будет содержать "темные углы". В придачу к темным углам языка добавляются темные углы DSL.
Если есть DSL, то он должен быть проще чем вызов методов. Поэтому учить его должно быть не сложнее, чем изучать семантику методов. Иначе он обычная ошибка проектирования и доставляет проблем столько же сколько любая другая ошибка проектирования.
ARK>В общем, DSL нужен только когда без него вообще не обойтись. И это надо в каждом конкретном случае показать.
В простых DSL совершенно простой синтаксис. Его учить не дольше, чем аналогичный API.
Re[12]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, AlexRK, Вы писали:
ARK>>Когда имеешь дело с библиотекой, надо выяснить только семантику методов. Когда с DSL — надо еще и синтаксис ковырять. Очевидно, что писать совсем простой DSL не имеет смысла. А немаленький DSL надо, во-первых, проектировать (что уже само по себе сложно), во-вторых он по любому будет содержать "темные углы". В придачу к темным углам языка добавляются темные углы DSL.
Z>Если есть DSL, то он должен быть проще чем вызов методов. Поэтому учить его должно быть не сложнее, чем изучать семантику методов.
Думаю, что он не проще, а просто позволяет короче записать нечто. Это вовсе не означает проще.
Z>Иначе он обычная ошибка проектирования и доставляет проблем столько же сколько любая другая ошибка проектирования.
Не уверен. Ошибка проектирования DSL будет стоить дороже, ИМХО. Знания внутреннего DSL в резюме не потребуешь. Сделали кривой DSL, наклепали на нем кучу кода и создатель уволился. КАК это все разгрести? Ковырять исходники компилятора? А если там нашли ошибку? Это будет жесть. Причем вы будете один на один с этим языком и кучей говнокода на нем.
ARK>>В общем, DSL нужен только когда без него вообще не обойтись. И это надо в каждом конкретном случае показать.
Z>В простых DSL совершенно простой синтаксис. Его учить не дольше, чем аналогичный API.
Только вот не надо его просто так учить (и делать DSL тоже). Надо если (и только если) будет показано, что DSL сократит объем кода в 10 раз, например.
Re[13]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
Z>>Если есть DSL, то он должен быть проще чем вызов методов. Поэтому учить его должно быть не сложнее, чем изучать семантику методов.
ARK>Думаю, что он не проще, а просто позволяет короче записать нечто. Это вовсе не означает проще.
Regexp, SQL, format strings — это примеры DSL которыми мы все пользуемся постоянно. Любая безDSLная альтернатива будет на порядки сложнее в применении. Причем для SQL и регэкспов она вообще за гранью реальности.
ARK>Не уверен. Ошибка проектирования DSL будет стоить дороже, ИМХО. Знания внутреннего DSL в резюме не потребуешь. Сделали кривой DSL, наклепали на нем кучу кода и создатель уволился. КАК это все разгрести? Ковырять исходники компилятора? А если там нашли ошибку? Это будет жесть. Причем вы будете один на один с этим языком и кучей говнокода на нем.
Ты не встречал проблем, когда создана кривая библиотека, используемая повсеместно, а создатель уволился? И единственный выход, переписать все? А если вы купили коммерческую библиотеку, а в ней баг и ее перестали поддерживать? Проблемы ровно того же порядка.
Z>>В простых DSL совершенно простой синтаксис. Его учить не дольше, чем аналогичный API.
ARK>Только вот не надо его просто так учить (и делать DSL тоже). Надо если (и только если) будет показано, что DSL сократит объем кода в 10 раз, например.
. Что тут учить? Разница тут далеко не на порядок, но и создать его очень просто, там не больше 40 строк кода. Простые DSL как раз самые дешевые и эффективные. Бояться проблем от них — чистое суеверие.
Здравствуйте, Mamut, Вы писали:
M>DSL не обязательно вводит новые синтаксические конструкции. А в printf конструкции форматирования вполне могут считаться DSL'ем, имхо.
Хотелось бы увидеть альтернативы этим DSL, ну и документацию к ним. Чтобы все, наконец, смогли понять чего следует бояться в DSL.
Re[14]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Regexp, SQL, format strings — это примеры DSL которыми мы все пользуемся постоянно. Любая безDSLная альтернатива будет на порядки сложнее в применении. Причем для SQL и регэкспов она вообще за гранью реальности.
"Если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то теперь у вас две проблемы" (с)
Кстати, шутка-то с долей шутки. Иные regexp-ы лучше бы расписать десятком методов — хоть понятно будет (всем будет понятно, а не одному гуру в толстых очках с черепаховой оправой).
SQL хороший DSL. Только он разрабатывался не за неделю на коленке местным архитектором, а умными людьми. Он общепризнан, по нему полно документации. И то часто возникают проблемы. Но с SQL решение проблемы найти элементарно, а вот с самописным языком...
Z>Ты не встречал проблем, когда создана кривая библиотека, используемая повсеместно, а создатель уволился? И единственный выход, переписать все? А если вы купили коммерческую библиотеку, а в ней баг и ее перестали поддерживать? Проблемы ровно того же порядка.
Бывает. С проблемами в неподдерживаемой либе иногда сталкиваемся.
Со своей библиотекой (и уволившимся создателем) проще все-таки. Синтаксис всем известен, работают тулы, рефакторинги и прочая.
А вот с DSL асимптотика проблемы может и такая же, но еще есть большая скрытая константа, усугубляющая дело. ИМХО.
Есть груда непонятного кода и компилятор, обрабатывающий этот код по своим правилам (с высокой долей вероятности содержащий ошибки и непредвиденные побочные эффекты).
Z>Ок, давай обсудим простые DSL. Вот пример простого самописного DSL
. Что тут учить? Разница тут далеко не на порядок, но и создать его очень просто, там не больше 40 строк кода. Простые DSL как раз самые дешевые и эффективные. Бояться проблем от них — чистое суеверие.
Лично мое мнение — я бы убрал из проекта все эти мелкие DSL. Глаз сразу выцепляет чужеродный код и внутри сразу возникает напряжение: ЧТО ЭТО? Зачем это нужно, излишнее усложнение на ровном месте? Мало того, что надо держать проблему в голове, еще натыкаешься на такие "упрощения" и это сразу сбивает с панталыку. Стандартного сахара в современных языках и так достаточно, а со своими мини-языками вместо кода получаем цветастое эклектичное полотно непонятно чего, дополненное потенциальными проблемами в макросах-компиляторах (которых даже если сейчас нет, то вполне могут появиться потом). И ради чего? Ради убирания двух-трех идентификаторов. За которые глаз программиста, кстати, "цепляется" при чтении кода.
Re[10]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Z>Давай я уточню свою позицию, "DSL обычно документированы" относится только к нормальным DSL готовым к использованию.
Бла-бла-бла. Сказки в детский сад. Примеры я тут приводил.
Z>Я не рассматриваю DSL которые могут быть созданы по желанию левой пятки не пойми кого. Этот не пойми кто сейчас создает говнокод, который не лучше и не хуже гипотетического DSL, но нам-то этого какая беда и зачем мы вообще об этом говорим?
Ну да. «Я говорю только о том, что мне удобно, ко всему остальному у меня позиция страуса».
Z>Если у тебя доводы в пользу того, что DSL намного сложнее документировать и это является значимой проблемой DSL ты приводи доводы а не цепляйся к словам.
Я нигде не говорил про то, что DSL намного сложнее документировать.
M>>Хотя понятно, что можно привести совершенно противоположныей пример. и даже в твоем insert into возникает толпа вопросов: что возврашает этот код? Что произойдет, если b уже существует в a и т.п.
Z>Это контр-пример? Что возвращает Insert? Что произойдет если b уже существует в а?
Я про это и говорю, блин. Нет у DSL никакой магической самодокументируемости
Z>>>DSL от аналогичной библиотеки отличается только тем, что у них разные синтаксисы. Но тот или другой все равно придется учить. И в каких-то предметных областях DSL получается проще чем родной синтаксис языка.
M>>Ключевое: каких-то. Ключевое: надо учить. Ключевое: документация Если DSL-и начнут клпеать все, кому не лень, сказки про «DSL обычно документирован» можно пешим строем отправлять в детский сад. Хотя, по большому счету, их надо туда отправлять уже сейчас.
Z>А зачем тебе юзать DSL который клепают все кому не лень и зачем мы это обсуждаем? Иерархии классов клепают все кому не лень, документируют обычно никак, ООП на помоечку что ли?
Я нигде не говорю, что DSL надо на помойку. Я просто говорю, что фраза «DSL обычно документированы» — это ложь.
Z>>>К примеру, в ruby уже невозможно провести черту между DSL и обычным API. Можно, например, сказать, что рельсы это DSL для веб разработки. А можно, что это всего лишь набор из нескольких слабо связанных библиотек, каждая из которых выполняет свою функцию.
M>>Безусловно. И, как любая библиотека, она требует изучения и документации. Никакого «обычно документирован» там нет и не прдевидится.
Z>Рельсы плохо документированы?
Сейчас — уже нет. И то, там наверняка есть множество темных мест, особенно в сторонних расширениях
Z>Где примеры плохих DSL? Ок, давай выкинем из спора DSL и начнем спорить о том, документированы ли обычно библиотеки. Примерно эту тему ты до сих пор пытаешься развить.
Я просто говорю, что фраза «DSL обычно документированы» — это ложь. DSL «обычно документированы» не лучше и не хуже любого другого кода.
M>>Я вообще не про это говорил, если что.
Z>О чем ты говорил? О том, что миллионы индусов наклепают тонны недокументированных DSL и наступит ад? Почему ты до сих пор можешь работать, хотя они наклепали тонну аналогичных библиотек?
Почему ты уверен, что каждый DSL — это именно библиотека, которая обязательно документирована? Откуда у тебя берется такая уверенность?
За которые глаз программиста, кстати, "цепляется" при чтении кода.
