А при чем тут DSL? (в продолжении темы о языках общего назначения) - Философия программирования

Z>>>Обычно документированный.

M>>С какого перепугу?

Z>Безо всякого перепуга, его документируют обычно не хуже чем альтернативный API.

Откуда берется этот «обычно». Особенно если мы говорим о светлом будущем, когда DSL'и будет писать каждый первый для каждой второй задачи.

M>>У нас на работе используется 3, по сути DSL'я. Уровень документации во всех трех — аховый. Без-DSLная алтернатива — описывать все то же в Erlang'е.
Z>А как писать все то же, но в Erlange документировано лучше?

Нет, конечно.

Z>Ты примеры давай, я тебе верю конечно на слово, но без примеров дискутировать не очень интересно.

Ты выдвинул утверждение, что DSLи будут документированы, ты его и доказывай.

M>>Осталось понять, каким образом такой хороший DSL может появиться. Это во-первых. Во-вторых — выделенное.

Z>Так же как и любой другой код для повторного использования. Он появляется потому, что без него еще хуже. А уж будет этот код документирован и продуман не зависит от того, DSL это или нет.

Я об этом и говорю. Никакого «обычно» не будет. Он будет документирован не лучше и не хуже, чем любой другой код. Хотя, учитывая, что это будет domain-specific language, то будет документирован еще хуже, так как в условиях «о, у нас домен, давай колбасить DSL» никто не будет выписывать весь синтаксис, семантику и т.п.

Здравствуйте, Ikemefula, Вы писали:

I>Это причина неприятия всех околонемерлевских проектов. Вместо того что бы предложить решение популярных задач, они упорно выдают решения калькуляторов или задач которые общей массе ввобще неизвестны.

I>Как то так выходит, что самые лучшие примеры по ДСЛ и Немерле от людей, которые мягко говоря не в ладах с местными немерлистами.

А что тут удивительного? Ведь DSL — DOMAIN specific language. Предметная область действия разработчиков Немерле — разработка Немерле (кэп на связи). Поэтому они и мыслят в первую очередь об этом, и создают макросы, упрощающие жизнь им самим.
А примеры не из мира компиляторостроения должны выдавать разрабы, не создающие сам N, а пользующиеся им.

I>Думаю не дальше чем через пару страниц от вас снова появятся автоматы, калькуляторы, пермишны и прочая ерунда которая оскомину набила еще лет пять назад.

Потому что калькуляторы и пермишны — это предметная область. Тому кто разбирается в этой области, нужно именно это. Для другой области деятельности — нужны свои языки.

Внезапно подумалось: вообще-то, это даже хорошо. Ведь часто встречаются ситуации, когда код пишет (или правит) человек, не владеющий спецификой предметной области. Имеется в виду код на ЯОН. А если код будет написан на DSL, то в него просто так не влезет посторонний. В какой-то мере это будет способствовать тому, что люди не разбирающиеся в данной области, не будут совать свои грязные ручонки в код.

Здравствуйте, koodeer, Вы писали:

K>А что тут удивительного? Ведь DSL — DOMAIN specific language. Предметная область действия разработчиков Немерле — разработка Немерле (кэп на связи). Поэтому они и мыслят в первую очередь об этом, и создают макросы, упрощающие жизнь им самим.
K>А примеры не из мира компиляторостроения должны выдавать разрабы, не создающие сам N, а пользующиеся им.

Другой кэп хотел бы сказать, что решение задачи по переходу в реальный мир в таком случае — проблема этих разработчиков. Неужели у них не хватает фантазии адаптировать любую из реальных задач к учебному виду?

K>Внезапно подумалось: вообще-то, это даже хорошо. Ведь часто встречаются ситуации, когда код пишет (или правит) человек, не владеющий спецификой предметной области. Имеется в виду код на ЯОН. А если код будет написан на DSL, то в него просто так не влезет посторонний. В какой-то мере это будет способствовать тому, что люди не разбирающиеся в данной области, не будут совать свои грязные ручонки в код.

Если "они" увидят знакомые слова, они подставят другие знакомые слова и без понимания деталей происходящего.
Чтобы такого не случилось, нужен другой язык.

Здравствуйте, Mamut, Вы писали:

M>Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.

Почему сразу недокументированный? Вероятность того, что DSL будет недокументирован равна вероятности того, что обычная библиотека классов будет недокументированной. Да, бывает такое. Но какая разница, будет нам непонятно ключевое слово foo в некоем DSL, или название метода foo() в некоей библиотеке?

Насчёт инструментария. Вроде как в N2 обещаны золотые горы. Ждём-с.

M>Потому что даже в том же SQL, который является DSL'ем с собственным стандартом и основан на известной мат. модели, разные реализации имеют собственные детали, инструменты, уровень документированности и проч. Про мелкие DSL'и, которые здесь пытаются активно продивигать (типа «каждой задаче по DSLю») я вообще промолчу.

А что плохого в микроDSL? Например, вот такой макрос NotNull. Или предлагаемый макрос INotifyPropertyChanged. Сокращение кода — на порядок. Понятность — имхо, выше некуда.

Здравствуйте, koodeer, Вы писали:

I>>Как то так выходит, что самые лучшие примеры по ДСЛ и Немерле от людей, которые мягко говоря не в ладах с местными немерлистами.

K>А что тут удивительного? Ведь DSL — DOMAIN specific language. Предметная область действия разработчиков Немерле — разработка Немерле (кэп на связи). Поэтому они и мыслят в первую очередь об этом, и создают макросы, упрощающие жизнь им самим.
K>А примеры не из мира компиляторостроения должны выдавать разрабы, не создающие сам N, а пользующиеся им.

Ага, должны. А что еще должны эти разрабы ?
Обычно разработчики инструментария обычно хорошо в курсе потребностей своей целевой аудитории.
А вот немерлисты почему то хорошо в курсе только компиляторов. Так шта...

I>>Думаю не дальше чем через пару страниц от вас снова появятся автоматы, калькуляторы, пермишны и прочая ерунда которая оскомину набила еще лет пять назад.

K>Потому что калькуляторы и пермишны — это предметная область. Тому кто разбирается в этой области, нужно именно это. Для другой области деятельности — нужны свои языки.

Спасибо, Кеп, только я про популяризацию, а не про это. Перечислены задачки вобще говоря так себе, мягко говоря. Напримеh калькуляторы всерьез никто не пишет, хватает того что идет в комплекте с любой ОС. Для автоматов уже давно есть отработаные инструменты и подходы и с ними одна проблема — текст майнтейнить на порядок сложнее чем диаграму.

K>Внезапно подумалось: вообще-то, это даже хорошо. Ведь часто встречаются ситуации, когда код пишет (или правит) человек, не владеющий спецификой предметной области. Имеется в виду код на ЯОН. А если код будет написан на DSL, то в него просто так не влезет посторонний. В какой-то мере это будет способствовать тому, что люди не разбирающиеся в данной области, не будут совать свои грязные ручонки в код.

Конкретному программисту это разумеется хорошо — можно диктовать условия заказчику ибо найти замену будет крайне сложно.
А вообще такие вопросы решаются административными мерами, а не языком программирования.

Здравствуйте, netch80, Вы писали:

K>>А что тут удивительного? Ведь DSL — DOMAIN specific language. Предметная область действия разработчиков Немерле — разработка Немерле (кэп на связи). Поэтому они и мыслят в первую очередь об этом, и создают макросы, упрощающие жизнь им самим.
K>>А примеры не из мира компиляторостроения должны выдавать разрабы, не создающие сам N, а пользующиеся им.

N>Другой кэп хотел бы сказать, что решение задачи по переходу в реальный мир в таком случае — проблема этих разработчиков. Неужели у них не хватает фантазии адаптировать любую из реальных задач к учебному виду?

Спасение утопающих дело сами утопающих

M>>Не знаю. У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.

K>Почему сразу недокументированный? Вероятность того, что DSL будет недокументирован равна вероятности того, что обычная библиотека классов будет недокументированной. Да, бывает такое. Но какая разница, будет нам непонятно ключевое слово foo в некоем DSL, или название метода foo() в некоей библиотеке?

Потоворяю еще раз. Для непонятливых. Тут активно педалируется идея того, что DSLи надо писать и они будут писаться всеми на каждый чих. Нет, это не будет библиотекой классов. Это будет еще одним куском кода в проекте. Как обстоит дело с документацией обычного повседневного кода в обычном проекте?

Вот есть у нас DSL: http://www.erlang-factory.com/upload/presentations/633/Metaprogramming.pdf страница 18-22. Когда этот DSL начинался, он был банально уровня на стр. 18. Потом туда добавились first of/all of, со страницы 19. А потом еще появился input() со страницы 20. А потом...

Стоит ли говорить, что документация (если она есть) присутсвует только кусками в коде и в голове людей, которые это дело писали или требовали таких изменений и сейчас с этим работают.

Поэтому повторю вопрос: откуда взялся этот миф, что DSLи обычно документированы? Это — ложь. Они будут документированы не больше и не меньше, чем любой другой код.

K>Насчёт инструментария. Вроде как в N2 обещаны золотые горы. Ждём-с.

M>>Потому что даже в том же SQL, который является DSL'ем с собственным стандартом и основан на известной мат. модели, разные реализации имеют собственные детали, инструменты, уровень документированности и проч. Про мелкие DSL'и, которые здесь пытаются активно продивигать (типа «каждой задаче по DSLю») я вообще промолчу.

K>А что плохого в микроDSL? Например, вот такой макрос NotNull. Или предлагаемый макрос INotifyPropertyChanged. Сокращение кода — на порядок. Понятность — имхо, выше некуда.

МикроDSL — еще куда ни шло. Пока эти самые microDSL не выливаются в толпу микроДСЛей, нагроможденных друг на друга

Здравствуйте, Mamut, Вы писали:

M>Они будут документированы не больше и не меньше, чем любой другой код.

Дык твои оппоненты говорят ровно то же самое. Что обычная либа, что DSL — никакой разницы. Только DSL типа компактнее.

M>МикроDSL — еще куда ни шло. Пока эти самые microDSL не выливаются в толпу микроДСЛей, нагроможденных друг на друга

Как раз микроDSL-и только так в такую толпу выливаются. Что мы и имеем на скале. Поэтому лично я сильно против них. Почему-то один сложный DSL уровня SQL, полезность которого очевидна, запоминается легче, чем того же суммарного объёма 100500 мелких разрозненных примочек там да сям, без которых вроде бы и так неплохо жилось.

Здравствуйте, Mamut, Вы писали:

M>Потоворяю еще раз. Для непонятливых. Тут активно педалируется идея того, что DSLи надо писать и они будут писаться всеми на каждый чих. Нет, это не будет библиотекой классов. Это будет еще одним куском кода в проекте. Как обстоит дело с документацией обычного повседневного кода в обычном проекте?

M>Вот есть у нас DSL: http://www.erlang-factory.com/upload/presentations/633/Metaprogramming.pdf страница 18-22. Когда этот DSL начинался, он был банально уровня на стр. 18. Потом туда добавились first of/all of, со страницы 19. А потом еще появился input() со страницы 20. А потом...

M>Стоит ли говорить, что документация (если она есть) присутсвует только кусками в коде и в голове людей, которые это дело писали или требовали таких изменений и сейчас с этим работают.

В моём понимании как: в процессе написания некоего кода происходит осознание, что часть кода повторяется, и тогда его можно вынести в отдельную функцию/класс. При этом иногда может быть сделано описание (документация) для этой функции/класса. В ряде случаев, когда невозможно обойтись привычными средствами (класс/функция), может помочь метапрограммирование: часть кода будет вынесена в макрос. Точно также может быть сделано (или не сделано) описание этого макроса. Моё видение вопроса в том, что степень документированности ничуть не ухудшится и не улучшится, она останется на том же уровне. Но количество кода сократится (что уже хорошо).

M>Поэтому повторю вопрос: откуда взялся этот миф, что DSLи обычно документированы? Это — ложь. Они будут документированы не больше и не меньше, чем любой другой код.

Согласен. Тут у нас консенсус. Степень документированности одинаковая. Но кода-то в разы (потенциально) меньше!

D>Здравствуйте, Mamut, Вы писали:
M>>Они будут документированы не больше и не меньше, чем любой другой код.
D>Дык твои оппоненты говорят ровно то же самое. Что обычная либа, что DSL — никакой разницы. Только DSL типа компактнее.

Нет. Мои оппоненты говорят следующее, цитирую:

M> что любой DSL — это еще один язык, зачастую недокументированный

Обычно документированный.

Я не согласен с выделенным. Нет никакого «обычно».

M>>МикроDSL — еще куда ни шло. Пока эти самые microDSL не выливаются в толпу микроДСЛей, нагроможденных друг на друга

D>Как раз микроDSL-и только так в такую толпу выливаются. Что мы и имеем на скале. Поэтому лично я сильно против них. Почему-то один сложный DSL уровня SQL, полезность которого очевидна, запоминается легче, чем того же суммарного объёма 100500 мелких разрозненных примочек там да сям, без которых вроде бы и так неплохо жилось.

Да, согласен. Но DSL объема SQL должен быть документирован

И хоть как-то стандартизирован, хотя бы в пределах компании. Потому что даже с SQL'ем можно напороться на интересные отличия между диалектами.

M>>Поэтому повторю вопрос: откуда взялся этот миф, что DSLи обычно документированы? Это — ложь. Они будут документированы не больше и не меньше, чем любой другой код.

K>Согласен. Тут у нас консенсус. Степень документированности одинаковая. Но кода-то в разы (потенциально) меньше!

И?

Продолжаю повторять:

любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой

Он будет документирован не лучше и не хуже, чем любой другой код. Хотя, учитывая, что это будет domain-specific language, то будет документирован еще хуже, так как в условиях «о, у нас домен, давай колбасить DSL» никто не будет выписывать весь синтаксис, семантику и т.п.

Я ссылку не зря привел. Казалось бы — там простой код, ага, его в разы меньше, ага. Я могу специально для тебя привести все 100% документации, что есть по этому языку:

Klarna Policy Language

* Overview

kpl implements Klarna Policy Language, a wiki-style language to express
policy rules. The language can be extended by additional functions that can
be invoked from the policy rule. For example, the function "lookup" is used
in acceptance rules to lookup information from external providers.

This application is side-effect free, it contains a compiler and an evaluator.

Всё

При том, что реализация этого языка — достаточно хорошо документирована, да. Например:

%% @spec equal(R::rule()|group()|seq(), R0::rule()|group()|seq()) -> bool()
%% @doc Equality test on data structures (ignores line number differences)
%%      see policy_rules.hrl for details; this is kept as simple as possible
%% @end

(только вот policy_rules.hrl в проекте давно отсутсвует, но это же меловчи, правда?)

И даже формальная грамматика в формате yecc есть. Например:

comp_expr -> concat_expr '=/=' concat_expr: #op{name='=/=', args=['$1', '$3']}.

И сами файлы местами документированы, но в терминах области (типа «если мы в Германии и клиенту меньше 18, даем отлуп, см. тикет XXX-123»).

Но я, надеюсь, ты согласишься, что это все не является заменой по документации по синтаксису и семантике DSLя, его возможностям, и т.п.? Поэтому я и повторяю: не надо рассказывать сказки, что DSL'и обычно документированы, или что их краткость каким-то образом компенсирует то, что они документированы не лучше остального кода.

Здравствуйте, Mamut, Вы писали:

K>>Согласен. Тут у нас консенсус. Степень документированности одинаковая. Но кода-то в разы (потенциально) меньше!

M>И?

В меньшем количестве кода легче разобраться. Даже без документации.
А с учётом того, что разрабу приходится писать меньше кода, у него останется больше времени, что может сподвигнуть на создание документации.

M>Продолжаю повторять:
M>

M>любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой

И?
В обычных библиотеках тоже бывает разный синтаксис.
Насчёт семантики сложно сказать. По идее, она соответствует предметной области. Если человек владеет ей (а он обязан ей владеть, если уж стал писать код), то легко поймёт DSL.

M>Я ссылку не зря привел. Казалось бы — там простой код, ага, его в разы меньше, ага. Я могу специально для тебя привести все 100% документации, что есть по этому языку:

Точно также можно привести кучу примеров обычных библиотек, в которых невозможно разобраться даже с обширной документацией.

M>Но я, надеюсь, ты согласишься, что это все не является заменой по документации по синтаксису и семантике DSLя, его возможностям, и т.п.? Поэтому я и повторяю: не надо рассказывать сказки, что DSL'и обычно документированы, или что их краткость каким-то образом компенсирует то, что они документированы не лучше остального кода.

Так я не рассказывают сказки. И не уверяю, что DSLи лучше/хуже документированы.
Однако я считаю, что краткость кода способствует лучшему пониманию. Это первое.
Второе: именно метапрограммирование в ряде случаев помогает в разы сократить количество кода.

Дело в том, что в реальной практике приходится очень много писать тонны копипасты, о чём писал WolfHound. Тот же пример с INotifyPropertyChanged. Макросы позволяют избежать этого, избавляют от рутины.
Практически все виденные мною примеры простых макросов понятны без всякой документации, при условии, что я уже знаком с тем, что этот макрос заменяет (пример: замена assert'а макросом NotNull). Все опробованные мною примеры больших DSL: SQL, LINQ — имеют хорошую документацию, и опять же полностью понятны.
На этом основании я смотрю на развитие dsl-строения с оптимизмом.

Здравствуйте, koodeer, Вы писали:

K>Дело в том, что в реальной практике приходится очень много писать тонны копипасты, о чём писал WolfHound. Тот же пример с INotifyPropertyChanged. Макросы позволяют избежать этого, избавляют от рутины.
K>Практически все виденные мною примеры простых макросов понятны без всякой документации, при условии, что я уже знаком с тем, что этот макрос заменяет (пример: замена assert'а макросом NotNull). Все опробованные мною примеры больших DSL: SQL, LINQ — имеют хорошую документацию, и опять же полностью понятны.
K>На этом основании я смотрю на развитие dsl-строения с оптимизмом.

Ну называть линк большим DSL — это ты канеш разогнался

как тут ужо говорили, линк — стандартизирован, ровно как и сикуль. Со стандартизированными дслями — нет проблем; проблемы бывают, когда он не стандартизирован и писал его Вася, который уволился пол года назад, и тогда начинаются проблемы в стиле: что же Вася нахреначил-то, а это тот еще ад и содомия, сталкивался с этим на предыдущей работе.

M>>И?

K>В меньшем количестве кода легче разобраться. Даже без документации.
K>А с учётом того, что разрабу приходится писать меньше кода, у него останется больше времени, что может сподвигнуть на создание документации.

Сказки, пожалуйста в детский сад

M>>Продолжаю повторять:
M>>

M>>любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой

K>И?
K>В обычных библиотеках тоже бывает разный синтаксис.
K>Насчёт семантики сложно сказать. По идее, она соответствует предметной области. Если человек владеет ей (а он обязан ей владеть, если уж стал писать код), то легко поймёт DSL.

Есть две большие разницы между понимать и писать. При том, что понять можно неправильно.

M>>Я ссылку не зря привел. Казалось бы — там простой код, ага, его в разы меньше, ага. Я могу специально для тебя привести все 100% документации, что есть по этому языку:
K>Точно также можно привести кучу примеров обычных библиотек, в которых невозможно разобраться даже с обширной документацией.

Ты не поверишь, но именно об этом я и говорю. Нет никакого магического DSL'я, у которого «обычно есть документация». Так же, как не бывает магических библиотек, у которых она «обычно есть».

M>>Но я, надеюсь, ты согласишься, что это все не является заменой по документации по синтаксису и семантике DSLя, его возможностям, и т.п.? Поэтому я и повторяю: не надо рассказывать сказки, что DSL'и обычно документированы, или что их краткость каким-то образом компенсирует то, что они документированы не лучше остального кода.

K>Так я не рассказывают сказки. И не уверяю, что DSLи лучше/хуже документированы.
K>Однако я считаю, что краткость кода способствует лучшему пониманию. Это первое.

Не всегда, не везде, и этоне значит, что коращение кода компенсирует, например, недостаток документации.

K>Второе: именно метапрограммирование в ряде случаев помогает в разы сократить количество кода.

Покажи мне, где я с этим спорю.

K>Дело в том, что в реальной практике приходится очень много писать тонны копипасты, о чём писал WolfHound. Тот же пример с INotifyPropertyChanged. Макросы позволяют избежать этого, избавляют от рутины.

Какое это отношение имеет к тому, о чем я говорю?

K>Практически все виденные мною примеры простых макросов понятны без всякой документации, при условии, что я уже знаком с тем, что этот макрос заменяет (пример: замена assert'а макросом NotNull). Все опробованные мною примеры больших DSL: SQL, LINQ — имеют хорошую документацию, и опять же полностью понятны.

Выделенное — ключевое. Откуда возьмется это знание?

K> На этом основании я смотрю на развитие dsl-строения с оптимизмом.

Это потому что, по товим же словам, все опробованные тобой большие DSLи — это SQL и LINQ. Задолбался повторять, но приходится: при условии, что DSL сможет писать каждый первый для каждой второй предметной области, не стоит на деяться на то, что эти DSLи будут магическим образом моментально понятны или обретут документацию.

Предлагаю разобраться в «коротком коде, который понятен без документации» тех же LINQ'а и SQL'я или любого другого DSLя

От:	hardcase	http://nemerle.org
Дата:	31.12.12 18:35
Оценка:

От:	hardcase	http://nemerle.org
Дата:	31.12.12 18:36
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	31.12.12 18:38
Оценка:

От:	hardcase	http://nemerle.org
Дата:	31.12.12 18:42
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	31.12.12 21:36
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	02.01.13 02:09
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	02.01.13 06:39
Оценка:

От:	dimgel	https://github.com/dimgel
Дата:	02.01.13 08:07
Оценка:	+1

	От:	Klikujiskaaan
	Дата:	02.01.13 09:37
	Оценка:	+4

	От:	minorlogic
	Дата:	01.01.13 12:35
	Оценка: