Пространно о DSL
10.04.2012
|
netch80
 |
Некоторые тезисы к обсуждению. Формулировки в заметной мере откорректированы с учётом уже сказанного в теме, как и вообще необходимость подобного постинга, хотя всё то же самое можно было сказать отдельно и независимо.
1. Каждый язык более высокого уровня является DSL, если сравнивать с языком более низкого уровня, с которым его можно напрямую соотнести.
Язык команд x86 является DSL по сравнению с языком микрокоманд конкретного Core Duo или Sandy Bridge. Доменом является переносимая система команд x86.
Язык C является DSL по сравнению с языком команд конкретных x86, ARM или любого другого процессора.
Доменом является виртуальная модель среды исполнения C, со всеми её ограничениями (например, не может быть двух разных входов в функцию или неопределённых аргументов).
Язык со сборкой мусора является DSL по сравнению с языком с ручным управлением памятью. Доменом является среда с гарантированной защитой от проблем ручного управления памятью и открытых указателей.
Декларативный язык является DSL по сравнению с процедурным языком. Доменом является поддержка описания зависимостей, условий и требований вместо ручного вычисления метода исполнения. Это в равной мере справедливо, например, для SQL и для Makefile.
2. Введение DSL, он же язык более высокого уровня, вызывается конкретным преимуществом его введения.
Типичными преимуществами являются:
Независимость от особенностей реализации (как переносимость системы команд, написания на C или доступные индексы для СУБД).
Устранение "геморроя", сиречь неприятных накладных расходов на реализацию. Характерный пример — ручное управление памятью.
Необходимость вывести определённые сущности из ментального поля автора реализации. Уже работа с указателями доступна не всем программистам, а учитывать сочетаемость акций в АЛУ конкретной модели сможет десяток человек по всему миру.
В заголовке этого пункта сделано отождествление DSL и языка высокого уровня (высота этого уровня относительна), что является натяжкой по сравнению с утверждавшимся в пункте 1. Это может показаться чрезмерным, но подождите до конца изложения.
3. DSL, он же язык более высокого уровня, имеет заметные недостатки по сравнению со своей альтернативой.
Написание в системе команд x86 требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом, когда все распределения действий максимально эффективно рассчитаны для конкретной модели процессора.
Написание на C требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом. (Чтобы в этом убедиться, достаточно поговорить с любым энтузиастом ассемблера.)
Написание на языке с автоматическим управлением памятью выливается в общеизвестные недостатки в виде непредсказуемого времени жизни и неравномерной производительности.
Кто-то сейчас скажет, что у него всё это заглажено; верю. Как и с любым другим конкретным примером здесь, важны не средние случаи, а крайние. Кроме того, сказано "заметные недостатки", а не "существенные".
4. Тем не менее, использование правильного DSL, он же язык более высокого уровня, предоставляет использующему заметные преимущества по сравнению с его неиспользованием.
Это не повторение пункта 2, потому что в пункте 2 утверждалось наличие преимущества без оценки его важности, а в данном уже рассматривается то, насколько он существенен с учётом и недостатков.
Пример с прямой работой с внутренностями процессора был бы самым показательным, потому что маргинальность такой работы ясна каждому. Именно поэтому он мне не нравится. SQL интереснее: каждый может в своём воображении залезть внутрь базы и напрямую поработать с таблицей, но большинство понимает, почему этого не следует делать. (Может, это вообще не таблица.) Интересен также случай с make, или с тем странным зверем по ссылке WolfHound'а, который по сути — супернавороченный make. Можно писать зависимости напрямую, но лучше воспользоваться для этого явным языком и оставить вычисление среде исполнения.
5. Понятие высокоуровневого языка программирования, сложившееся исторически и в основном разработанное в 1960-х годах, означает DSL.
Это не абсолютный принцип; есть заметные исключения в виде языков, которые позволяют делать почти всё, но при этом считаются высокоуровневыми из-за необходимости описать все детали и последствия. И именно они по факту малопопулярны и держатся только в особых средах. Примеры — Паскаль, который остался почти только в обучении, и Ada, которая держится только на стандартах военных заказчиков. Я не утверждаю, что они именно поэтому малопопулярны; этот вопрос требует отдельного изучения.
В основной же части отрасли высокий уровень определён обструктивно, то есть опре
деляется запретом, а не утверждением. Аналогично тому, как воспитание есть больше правила, что *не* делать, чем то, что делать, высокий уровень — это обещание безопасности (не в смысле посторонних вторжений, а в смысле реализации только того, что требуется) за счёт отказа от возможностей. См. пункт 3.
6. И наоборот, DSL в современном понимании неявно подразумевает отказ от возможностей, даже если это явно не формулируется.
Даже если какой-то DSL сделан тьюринг-полным за счёт возможности включить произвольные исполняемые участки кода, это не означает возможность делать что угодно в этом коде; сохраняется общая логика той среды, под которую рассчитан этот DSL. Например, код может быть вызван только по определённому действию пользователя. Многие DSL намеренно не предоставляют таких широких возможностей.
Ограничения являются и неизбежной, и необходимой оборотной стороной того преимущества, которое даёт конкретный DSL.
7. Языки более общего назначения (более низкоуровневые), несмотря на заголовок темы, имеют смысл.
Они имеют смысл, во-первых, потому, что на чём-то надо реализовать этот DSL. Этот фактор очевиден, но его не следует упускать в данной дискуссии.
Они имеют смысл, во-вторых, потому, что DSL всегда ограничен, а задачи — нет. Чем более низок уровень языка, тем меньше его надо менять под задачу.
8. Радикальные примеры показывают радикальные случаи, но не годятся для доказательства в общем.
Пример в стартовом письме данной темы является как раз таким радикальным случаем. Столько страстей, сколько в среднем фильме, вы можете не получить за всю жизнь, и такое же правило применимо и к программированию. Прорыв в 19 строк вместо ~4000 — дастся не каждому.
9. Введение DSL имеет смысл, если он упрощает реализацию не только текущей задачи, но и будущих задач.
10. Всё изложенное здесь нестрого и в принципе не может быть строгим.
Это связано с тем, что программирование в принципе не является строго формализуемой деятельностью.
Но это не значит, что не может быть чётких и однозначных случаев, которые можно классифицировать и сравнить в соответствии с изложенным выше. (Хотя их мало.)
11. Основная часть споров, происходящих здесь — это конфликты опыта и эмоций в недостаточно однозначных случаях.
Поэтому я не хотел вступать в тяжёлые дискуссии, которые тут заведомо неконструктивны.
---------------------------------------------------------------------------------------
Можно заметить, что процентов 90 споров ведётся между немерлистами и прочими, на тему того, насколько просто можно писать DSL.
Но синтаксис не является проблемой.
В конце концов, всегда можно откатиться на XML/JSON/etc., не к ночи будь сказано
Проблема — что именно в нём должно быть и чего не должно быть. А вот тут сложность фактически совпадает со сложностью придумывания нового языка программирования, и последствия те же — 99% этих языков гибнут не получив популярность.
В случае DSL обстановка чуть более тепличная. Угадать потребности проще, давление рынка и вкусовщины на сам язык слабее.
И это то, что никак не может быть решено никакими столь рекламируемыми здесь новшествами из N2.
Они дадут только облегчение разборки с синтаксисом. Семантику они не решат.
И именно поэтому описанное противостояние нелепо.
1. Каждый язык более высокого уровня является DSL, если сравнивать с языком более низкого уровня, с которым его можно напрямую соотнести.
Язык команд x86 является DSL по сравнению с языком микрокоманд конкретного Core Duo или Sandy Bridge. Доменом является переносимая система команд x86.
Язык C является DSL по сравнению с языком команд конкретных x86, ARM или любого другого процессора.
Доменом является виртуальная модель среды исполнения C, со всеми её ограничениями (например, не может быть двух разных входов в функцию или неопределённых аргументов).
Язык со сборкой мусора является DSL по сравнению с языком с ручным управлением памятью. Доменом является среда с гарантированной защитой от проблем ручного управления памятью и открытых указателей.
Декларативный язык является DSL по сравнению с процедурным языком. Доменом является поддержка описания зависимостей, условий и требований вместо ручного вычисления метода исполнения. Это в равной мере справедливо, например, для SQL и для Makefile.
2. Введение DSL, он же язык более высокого уровня, вызывается конкретным преимуществом его введения.
Типичными преимуществами являются:
Независимость от особенностей реализации (как переносимость системы команд, написания на C или доступные индексы для СУБД).
Устранение "геморроя", сиречь неприятных накладных расходов на реализацию. Характерный пример — ручное управление памятью.
Необходимость вывести определённые сущности из ментального поля автора реализации. Уже работа с указателями доступна не всем программистам, а учитывать сочетаемость акций в АЛУ конкретной модели сможет десяток человек по всему миру.
В заголовке этого пункта сделано отождествление DSL и языка высокого уровня (высота этого уровня относительна), что является натяжкой по сравнению с утверждавшимся в пункте 1. Это может показаться чрезмерным, но подождите до конца изложения.
3. DSL, он же язык более высокого уровня, имеет заметные недостатки по сравнению со своей альтернативой.
Написание в системе команд x86 требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом, когда все распределения действий максимально эффективно рассчитаны для конкретной модели процессора.
Написание на C требует слоя трансляции и уменьшает эффективность исполняемого кода по сравнению с возможным идеалом. (Чтобы в этом убедиться, достаточно поговорить с любым энтузиастом ассемблера.)
Написание на языке с автоматическим управлением памятью выливается в общеизвестные недостатки в виде непредсказуемого времени жизни и неравномерной производительности.
Кто-то сейчас скажет, что у него всё это заглажено; верю. Как и с любым другим конкретным примером здесь, важны не средние случаи, а крайние. Кроме того, сказано "заметные недостатки", а не "существенные".
4. Тем не менее, использование правильного DSL, он же язык более высокого уровня, предоставляет использующему заметные преимущества по сравнению с его неиспользованием.
Это не повторение пункта 2, потому что в пункте 2 утверждалось наличие преимущества без оценки его важности, а в данном уже рассматривается то, насколько он существенен с учётом и недостатков.
Пример с прямой работой с внутренностями процессора был бы самым показательным, потому что маргинальность такой работы ясна каждому. Именно поэтому он мне не нравится. SQL интереснее: каждый может в своём воображении залезть внутрь базы и напрямую поработать с таблицей, но большинство понимает, почему этого не следует делать. (Может, это вообще не таблица.) Интересен также случай с make, или с тем странным зверем по ссылке WolfHound'а, который по сути — супернавороченный make. Можно писать зависимости напрямую, но лучше воспользоваться для этого явным языком и оставить вычисление среде исполнения.
5. Понятие высокоуровневого языка программирования, сложившееся исторически и в основном разработанное в 1960-х годах, означает DSL.
Это не абсолютный принцип; есть заметные исключения в виде языков, которые позволяют делать почти всё, но при этом считаются высокоуровневыми из-за необходимости описать все детали и последствия. И именно они по факту малопопулярны и держатся только в особых средах. Примеры — Паскаль, который остался почти только в обучении, и Ada, которая держится только на стандартах военных заказчиков. Я не утверждаю, что они именно поэтому малопопулярны; этот вопрос требует отдельного изучения.
В основной же части отрасли высокий уровень определён обструктивно, то есть опре
деляется запретом, а не утверждением. Аналогично тому, как воспитание есть больше правила, что *не* делать, чем то, что делать, высокий уровень — это обещание безопасности (не в смысле посторонних вторжений, а в смысле реализации только того, что требуется) за счёт отказа от возможностей. См. пункт 3.
6. И наоборот, DSL в современном понимании неявно подразумевает отказ от возможностей, даже если это явно не формулируется.
Даже если какой-то DSL сделан тьюринг-полным за счёт возможности включить произвольные исполняемые участки кода, это не означает возможность делать что угодно в этом коде; сохраняется общая логика той среды, под которую рассчитан этот DSL. Например, код может быть вызван только по определённому действию пользователя. Многие DSL намеренно не предоставляют таких широких возможностей.
Ограничения являются и неизбежной, и необходимой оборотной стороной того преимущества, которое даёт конкретный DSL.
7. Языки более общего назначения (более низкоуровневые), несмотря на заголовок темы, имеют смысл.
Они имеют смысл, во-первых, потому, что на чём-то надо реализовать этот DSL. Этот фактор очевиден, но его не следует упускать в данной дискуссии.
Они имеют смысл, во-вторых, потому, что DSL всегда ограничен, а задачи — нет. Чем более низок уровень языка, тем меньше его надо менять под задачу.
8. Радикальные примеры показывают радикальные случаи, но не годятся для доказательства в общем.
Пример в стартовом письме данной темы является как раз таким радикальным случаем. Столько страстей, сколько в среднем фильме, вы можете не получить за всю жизнь, и такое же правило применимо и к программированию. Прорыв в 19 строк вместо ~4000 — дастся не каждому.
9. Введение DSL имеет смысл, если он упрощает реализацию не только текущей задачи, но и будущих задач.
10. Всё изложенное здесь нестрого и в принципе не может быть строгим.
Это связано с тем, что программирование в принципе не является строго формализуемой деятельностью.
Но это не значит, что не может быть чётких и однозначных случаев, которые можно классифицировать и сравнить в соответствии с изложенным выше. (Хотя их мало.)
11. Основная часть споров, происходящих здесь — это конфликты опыта и эмоций в недостаточно однозначных случаях.
Поэтому я не хотел вступать в тяжёлые дискуссии, которые тут заведомо неконструктивны.
---------------------------------------------------------------------------------------
Можно заметить, что процентов 90 споров ведётся между немерлистами и прочими, на тему того, насколько просто можно писать DSL.
Но синтаксис не является проблемой.
В конце концов, всегда можно откатиться на XML/JSON/etc., не к ночи будь сказано
Проблема — что именно в нём должно быть и чего не должно быть. А вот тут сложность фактически совпадает со сложностью придумывания нового языка программирования, и последствия те же — 99% этих языков гибнут не получив популярность.
В случае DSL обстановка чуть более тепличная. Угадать потребности проще, давление рынка и вкусовщины на сам язык слабее.
И это то, что никак не может быть решено никакими столь рекламируемыми здесь новшествами из N2.
Они дадут только облегчение разборки с синтаксисом. Семантику они не решат.
И именно поэтому описанное противостояние нелепо.
| 10.04.2012 27 комментариев |
N> [...]
Большое спасибо тебе, добрый человек netch80, ты прямо отдушина в этой традиционной РСДН-бойне. Это самый адекватный пост в этой теме.
Мне много лет приходится заниматься DSL-строением. Я никогда не задумывался над философией по этому поводу, и считал, что это именно DSL, но почитав тут много всякого, у меня сложилось впечатление, что на самом деле занимался какими-то "кривыми и ограниченными" языками (здесь можно увидеть пример, недавно консультировался у немерлистов по этому поводу).
И лично мне очень не хватает хорошего языка общего назначения, в том числе и для создания DSL.
N>Некоторые тезисы к обсуждению...
Буду краток — полный бред. Подменил понятие "ДСЛ" на понятие "Уровень языка", и выстроил на этом стройную, но бессмысленную картину. Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума. Синклер такой прям рьяный немерлист
Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.
На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
Плохой критерий.
Ибо так умеют все полные по Тьюрингу языки.
Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.
Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.
И 1Эс-язык не ДСЛ, только от того, что прибит гвоздями к специализированному рантайму и содержит в себе захардкоженый ДСЛ доступа к данным.
Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.
А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.
WH>>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
VD>Да, если это не следствие побочное эффекта вроде CTE в SQL или частичной специализации шаблонов С++ и если он имеет средства ввода вывода достаточные для решения задач разного рода.
Ну... JS не имеет встроенных ср-в ввода/вывода, зато имеет ср-ва для подачи хостом внешних ф-ий и переменных, которые скрипт видит как "свои". Т.е. язык остался тот же самый, с тем же синтаксисом и правилами, но стоит подать ему ф-ии общего назначения, и, согласно твоему определению, он превратится в язык общего назначения... А до этого кем был?
VD>Ни фига ВБА не ДСЛ. Он от ВБ6 ничем не отличается, кроме библиотеки предоставляемой вордом или экселм.
Если бы не возможность произвольного импорта внешних модулей в VBA, или не поданная хостом ф-ия CreateObject, позволяющая создать любой COM-объект, то был бы вполне себе DSL.
VD>Иначе Перл тоже ДСЛ. Да и вообще все на свете ДСЛ.
Вот. Об этом автор и говорил. К самому языку относят только его синтаксис, но тут выбор не разбежишься особо — в DSL приходится вкладывать синтаксические конструкции, которые есть и в обычных языках. Но возможности языка определяются доступным из него функционалом, а это уже не только синтаксис. Из скриптовых языков по умолчанию ничего не доступно. Это делает их удобной базой для создания DSL. Как популярный пример — куча DSL сверху LUA.
VD>А на фиг нужен термин не выражающий ничего? Для обозначения понятия язык программирования уже есть термин — язык программирования.
Он и есть язык программирования. Только domain-specific, то бишь специально заточенный на узкую область. Как JS в браузере, после того, как в него DOM страницы подали.
VD>>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
WH>Плохой критерий.
WH>Ибо так умеют все полные по Тьюрингу языки.
Не все. Для этого еще доступ к внешним ресурсам нужен.
WH>Соответственно если вдруг ДСЛ окажется полным по Тьюрингу, то он сразу перестает быть ДСЛ?
В общем — да. Как только язык становится универсальным, то он перестает быть ДСЛ-ем. Он становится специализированным (или не очень) ЯОН.
N>>Некоторые тезисы к обсуждению...
VD>Буду краток — полный бред.
В общем случае оно и не должно было быть не-бредом, потому что тезисы к обсуждению не должны быть истинными или даже адекватными. Они должны стать отправной точкой для дискуссии, и рассчитаны на то, чтобы получить конструктивный результат, даже если все они будут опровергнуты.
Но, с другой стороны, я не соглашусь с твоей оценкой их как бреда.
VD> Подменил понятие "ДСЛ" на понятие "Уровень языка", и выстроил на этом стройную, но бессмысленную картину.
Конечно, написать вместо трёх страниц три предложения — это архикруто. Странно, что ты их ещё не строишь в стиле WolfHound'а.
Мне бы хотелось увидеть критику попунктно и по существу. Пока что я не увидел ни одного опровержения тезису, что в формировании DSL ограничения не менее важны, чем упрощения и адаптации. Более того, они являются одним и тем же, и это ты тоже не опроверг.
И ты, очевидно, не заметил, что "уровень языка" здесь являлся только временным синонимом для визуализации связи с уже известными понятиями, но никак не первичным понятием.
VD> Выводы в конце вообще из пальца высосаны. За одно к "немерлистам" записал пол форума.
Нет, только двоих общеизвестных участников.
VD> Синклер такой прям рьяный немерлист
Я не вижу принципиально общего между позицией тебя и WH с одной стороны, и Синклера с другой. По-моему, они заметно различны. Докажи, если считаешь иначе.
VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.
VD>На то она и предметная область, чтобы решать только ее задачу. Если ДСЛ позволяет (пусть криво или медленно) воспроизвести себя, то это ЯОН (язык общего назначения). А его уровень не имеет никакого отношения к ДСЛ-ности.
Это уже раскритиковали, могу только согласиться с твоими оппонентами.
VD>Но пока читал все это сформулировал для себя очень простой критерий выявления ДСЛ-ей. ДСЛ не позволяет воспроизвети себя же, если это не ДСЛ описания компилятора.
Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?
Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.
Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.
Ну, вот скажем, HP-GL, вроде бы, бесспорно DSL. Он не тьюринг-полный, да и вообще плохо напоминает язык программирования.
А вот, скажем, ECMAScript — это ЯОН? Однозначно ЯОН.
Но в его синтаксис встроена специальная поддержка для regex-ов, что заставляет задуматься над "несимметричностью" его домена.
Или вот, скажем, фортран — это ЯОН? Судя по обилию произвольных программ, написанных на нём (скажем, бухгалтерию на нём в до-одинэсные времена писали — только в путь), он вполне себе ЯОН.
Но наличие в нём встроенного типа для комплексных чисел и всей нужной арифметики подсказывает нам, что разрабатывался он всё-таки для вычислительной математики.
В С++ нет встроенного типа complex. Зато есть возможность ввести его, и получить вполне приличный синтаксис. Грубо говоря, С++ — это язык для разработки кастомной арифметики. Вы посмотрите, сколько в нём любовного внимания уделено перегрузке операторов и тонкостям передачи данных "по значению". Бьярни явно хотелось порвать Фортран путём разработки движка для промышленного выпуска Фортранов. Зато вот строки в плюсах — бедный родственник (что по-прежнему лучше фортрана, в котором строки были прямо-таки чужаками). Видно, что авторы языка не хотели, чтобы на нём кто-то работал с текстами.
В итоге мы всё равно упираемся в сравнение тёплого с мягким. "Уровень" С++ в одних местах "выше", чем у С# 1.0 (позволяя описывать шаблонные функции и типы), а в других — "ниже" (требуя вручную управлять динамически распределённой памятью).
"Ширина" домена тоже штука плохо — домены могут пересекаться лишь частично, и непонятно, в ком из сравниваемых чего-то "не хватает".
И тем не менее, на бытовом уровне мы всё ещё можем сравнивать языки между собой, пусть и нечётко. Заголовок топика, хоть и крайне провокационный, всё же несёт здравое зерно.
На мой взгляд, оно как раз в стоимости разработки языков. Ну, то есть понятно, что исторически первыми появлялись именно DSL — фортран, алгол. Языки общего назначения были попыткой сэкономить на разработке и изучении множества DSL (помните Аду?).
Если посмотреть на то, с чем мы вышли из 80х, то в списке популярных мы будем иметь два языка, разработанных чисто для обучения (Pascal и Basic), два DSL, выросших в GPPL (Фортран и C), и C++.
В течение 30 лет народ тщательно пилил ЯОНы, пытаясь довести их до совершенства. Главная идея развития: давайте дадим возможность пилить библиотеки, и паническая боязнь встроить в язык хоть что-то конкретное. Надо полагать, всех пугала тень Ады. "Если дать человеку тип "строка", он проживёт один день. Если дать ему механизм реализации пользовательских типов строк и перегрузки операций, то он протрахается всю жизнь".
В 2000х пошла некоторая обратная тенденция: вместо механизмов по построению механизмов по решению задач, стало можно потихонечку внедрять просто механизмы по решению задач. Т.е. вносить некоторую доменную специфику.
В принципе, никто не будет спорить, что обжать разъём RJ-45 лучше при помощи обжимочного инструмента. Что заворачивать шурупы удобнее шуруповёртом, чем отвёрткой, и чем даже дрелью.
Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.
S>Есть подозрение, что если бы у нас был дешёвый способ клепать высококачественные языки для решения конкретных типов задач, то вряд ли бы мы стали от него отказываться, и стараться решить всё многословно, коряво, но зато на "универсальном" языке.
Так есть он, этот способ. Причем мало от языка зависящий.
O> Так есть он, этот способ. Причем мало от языка зависящий.
Расскажите.
S>Влад, я с этим не согласен. Ну ты же сам тут же делаешь оговорку. Чем DSL для разработки компиляторов хуже, чем DSL для описания фильтров для фотошопа?
Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.
S>Если отвлечься от специфики, то окажется, что у любого языка есть какой-то домен.
S>Бытовое понятие "языка общего назначения" обычно просто означает повышенную "ширину" домена, по сравнению с каким-то другим доменом.
Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
* языком на котором можно написать все, что угодно, но тем или иным образом используемым для решения некой задачи;
* и языком предназначенным для решения конкретной задачи и только ее.
Если такого различия не будет, то и говорить ДСЛ-ях будет невозможно, так как у дей будет каша в голове.
Уж слишком разные требования и свойства у этих вещей.
Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
VD>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.
Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).
VD>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?
VD>* языком на котором можно написать все, что угодно, но тем или иным образом используемым для решения некой задачи;
VD>* и языком предназначенным для решения конкретной задачи и только ее.
Мне кажется, ты сравниваешь полноту по тьюрингу с проблемно-ориенированностью.
На мой взгляд, они не являются взаимоисключающими.
VD>Уж слишком разные требования и свойства у этих вещей.
Не вижу особенных различий в требованиях. Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.
VD>Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?
S>Ну, а язык для компиляторов не обязан позволять написать фильтр. Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).
Самое смешное, что как раз язык для написания компиляторов и не должен быть Тьюринг-полным. Для него это крайне нежелательное свойство. Смотрите на Coq (и на CompCert за примером применения).
VD>>Ничем. Но ДСЛ для фильров не должен позволять написать ДСЛ для фильтров, а только фильтры.
S>Ну, а язык для компиляторов не обязан позволять написать фильтр.
Не. Не так... "язык для компиляторов обязан НЕ позволять написать фильтр"
Если он это позволяет, то мы имеем овердизайн. В лучшем случае инструментом будет сложно пользоваться.
S> Или, по крайней мере, написать его удобно (понятно, что любой тьюринг-полный язык сразу даст написать и фильтр, и компилятор с DSL).
Вот именно. Вот только удобнее получается только, если язык ограничен и специализирован.
VD>>Это бессмысленная философия. Должно быть различие между двумя совершенно разными вещами.
S>Развернём утверждение: если чёткого различия нет, то две вещи не являются совершенно разными. Не так ли?
Если, то нет. Но четкая разница есть.
Почитал книгу Фаулера Предметно-ориентированные языки программирования.
Другими словами — поддерживает мою точку зрения
S>Мне кажется, ты сравниваешь полноту по тьюрингу с проблемно-ориенированностью.
Я не сравниваю. Я считаю, что полнота по Тьюрингу — это признак ЯОН, но при некоторых оговорках. Скажем хотя SQL с CTE теоретически и стал полон по Тьюрингу, но написать на нем парсер будет крайне сложно. А вот на ВБА или 1Эс вполне.
S>На мой взгляд, они не являются взаимоисключающими.
Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.
Говоря о чем-то нужно пнимать о чем идет речь. При очень вольной трактовке понятния ДСЛ его просто нельзя использовать, так как одним и тем же термином описываются принципиально разные вещи.
ЯОН со встроенным ДСЛ-ем не превращается в ДСЛ. ЯОН прикрученный к Ворду или броузеру не становится ДСЛ.
И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.
Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему. Если можно — это почти наверняка не ДСЛ. Вот на 1Эс можно. А на SQL — нет.
Если для написания системы использует ДСЛ, то система уже обязана быть написана более чем на одном языке. Если это не так, то вас обманули.
VD>>Уж слишком разные требования и свойства у этих вещей.
S>Не вижу особенных различий в требованиях.
Это то и печально.
S> Вот, скажем, два языка — Паскаль и C++. Оба — GPPL ("можно написать все, что угодно"). Но в Паскале есть встроенная механика по работе с файлами фиксированной структуры (FILE OF TYPE), а С++ — механика перегрузки операторов. Почему? Надо полагать, у них отличаются домены.
Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
VD>>Кроме того тогда встает вопрс о том, что вместо ДСЛ можно использовать термин "язык". Ведь если мы дофилософствовались до того, что любой язык являетс ДС, то нафиг тогда нужна эта приставка?
S>Влад, с какого момента можно называть человека толстым? Где граница между "полным", "полноватым", и "склонным к полноте"?
Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.
VD>Говоря о чем-то нужно пнимать о чем идет речь. При очень вольной трактовке понятния ДСЛ его просто нельзя использовать, так как одним и тем же термином описываются принципиально разные вещи.
И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.
VD>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.
Ок, так тоже можно. Но даже если мы будем судить о DSL-ности по тому, чего именно нельзя на этом языке, всё равно у нас будет континуум таких языков.
VD>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.
Я уже в этой ветке писал, что это — не критерий. На языке C без использования других языков ничего полезного не напишешь, тупо потому, что в него кроме управляющих конструкций ничего не встроено. А библиотеки для него, обеспечивающие ему возможности для написания систем, написаны, очевидно, с использованием других языков.
VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.
VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.
Практика показывает, что толстость человека напрямую зависит от его окружения. В компании дистрофиков типа меня или Мерля любой покажется толстоватым.
А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
ВБА — не DSL. В нём нет никакой доменной специфики. Про 1С ничего не скажу, в связи с некомпетентностью в нём.
S>А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
S>ВБА — не DSL. В нём нет никакой доменной специфики. Про 1С ничего не скажу, в связи с некомпетентностью в нём.
VB6 — чистый DSL для создания простых UI (язык необязательно должен быть чисто текстовым). VB.NET — это уже другой синтаксис для С#.
1С — это целый комплекс, там язык не так важен, на самом деле.
S>И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.
Ты обычно радуешь меня тем, что в отличии от других философов пытаешься глубоко вникнуть в тему.
К сожалению, в этот раз ты этого не потрудился сделать. Попробуй еще раз.
Фаулер тоже философствует. Критерии действительно не четки. И XSTL — это забавный пример. В принципе XSTL отлично подходит под определение ДСЛ-я, но в погоне за гибкостью в XSTL были включены фичи которые позволяют использовать (и довольно эффективно) его не по назначению. Если XSTL начинает использоваться не для преобразования текста — это он сразу же превращается в ЯОН. Главное здесь, то что использование XSTL для рассчетов — это внеполовое извращение.
С другой стороны язык 1Эс по своему дизайну позволяет писать код вне предметной области на которую он рассчитан. При этом никаких извращений предпринимать не нужно, так как 1Эс — это полноценный процедурный язык. В нем есть универсальные штатные средства — циклы, процедуры, операторы условного преехода.
VD>>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.
S>Ок, так тоже можно. Но даже если мы будем судить о DSL-ности по тому, чего именно нельзя на этом языке, всё равно у нас будет континуум таких языков.
Нам нужно четко разделить ВБА, 1 Эс, SQL и регексы. SQL и регексы — это четкие представители того что я (и, как оказалось, Фаулер) называю ДСЛ-ем. ВБА — для меня вообще скрипт не имеющий к ДСЛ-ю никакого отношения. 1Эс — спорный вопрос, но я бы отнес его к специализированным ЯОН или даже к ЯОН с со встроенными ДСЛ-ями (хотя основную мощь в 1Эс определяет среда и встроенная модель).
Такое разделение нам необходимо для плодотворного обсуждения вопросов связанных с разработкой ДСЛ-ей.
На мой взгляд ДСЛ должен обладать одной моделью. Если язык штатно позволяет манипулировать несколькими моделями, то это уже ЯОН (или очень кривой ДСЛ).
Скажем моделью SQL является запрос к СУБД, ХСЛТ описывает модель трансформации ХМЛ, а моделью регексов — паттерн поиска подстроки в тексте. SQL, ХСЛТ и регексы всего лишь удобный синтаксис по заполнению соответствющих моделей. 1Эс же — это универсальный язык который позволяет в том числе манипулировать рядом моделей которые предоставляет среда 1Эс.
И это огромное различие. Под истенные ДСЛ можно подвести четкую иделогию:
1. Проектируем модель описывающую решаемую задачу.
2. Проектируем язык позволяющий максимально декларативно и понятно заполнить модель.
3. Делам компилятор или интерпретатор модели.
Все! Мы получили способ решения сложных проблем в любой области.
Для создания жерешений вроде 1Эс данная иделогия не применима, так как в 1Эс много моделей и связующего их кода. 1Эс можно представить как ряд ДСЛ-ей, часть из которых визуальные (формоклепство и описание отчетов).
VD>>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.
S>Я уже в этой ветке писал, что это — не критерий. На языке C без использования других языков ничего полезного не напишешь, тупо потому, что в него кроме управляющих конструкций ничего не встроено. А библиотеки для него, обеспечивающие ему возможности для написания систем, написаны, очевидно, с использованием других языков.
Ты опять извращаешь реальность. Библиотеки ни разу не отдельная сущность для ЯОН. У любого языка можно отнять библиотеки и он станет ограниченным в возможностях. Но это ни разу не меняет реальность.
Это ты выдумал сам, что ЯОН без библиотек чудесным образом превращается в ДСЛ. Но это не так! ЯОН позволяет описать модели прямо внутри себя и решить любые задачи без использования библиотек. Библиотеки только позволяют общаться с внешним миром.
VD>>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
S>Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.
У меня вообще нет авторитетов. Но мужик провел реальную работу по классификации я согласен с его выводами. Ну, и сам факт, что мое мнение не уникально уже косвенно подтверждает его правоту.
VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.
S>Практика показывает, что толстость человека напрямую зависит от его окружения. В компании дистрофиков типа меня или Мерля любой покажется толстоватым.
Опять софистика. По фигу в какой компании находится человек страдающий ожирением третьей степени. Весящие складки жира на боках, 3-ий подбородок — это трудно не заметить.
VD> Таким образом, несмотря на его ориентированность на предметную область, я бы не назвал его предметно-ориентированным языком.
5 баллов. "Несмотря на то, что эта ткань белого цвета, я бы не назвал её белой". Это везде так у Фаулера?
VD>Другими словами — поддерживает мою точку зрения
Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном
городеязыке N и других горячих темахА если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно. Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.
Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".
Прикидка определения каждого из этих понятий:
* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
* специализированность — адаптирован в целом (в общих принципах) под названную цель
* специфичность — реализация запросов за пределами названной цели заметно усложнена
* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели
они представляют собой последовательное усиление в сторону DSL, в том же порядке.
VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.
См. выше — должен быть не один критерий, а четыре.
VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
VD>В этом определении есть четыре ключевых элемента.
VD>* Язык программирования...
VD>* Природа языка...
VD>* Ограниченные выразительные возможности...
VD>* Ориентированность на предметную область...
VD>Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей. Многие используют буквальное определение DSL как язык для конкретной предметной области.
Во-во. Проблему он почувствовал, но выразить не супел.
VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.
N>Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном
городеязыке N и других горячих темахТы занимаешься демагогией. Он же привел отличный пример. Монеты ни разу не компакт-диски, не смотря на то, что они несомненно компактные, и несомненно диски.
Точно так же одно то, что язык используется для решения узкого круга задач, еще недостаточно для того чтобы называть его ДСЛ-ем. Он так же должен обладать ограниченными выразительными возможностями. Языки обладающие неограниченными выразительными возможностями не могут называться ДСЛ-ями. По сему 1Эс и ВБА не ДСЛ-и.
Серджинио тут где-то привел определение подходящее для 1Эс-ного язяка. Что-то типа предметно-ориентированный язык высокого уровня. Что можно перевести на детерминированный язык как заточенный под предмет ЯОН.
N>А если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно.
Я изначально сказал, что проблема терминологическая. ДСЛ слишком расплывчатый термин. И многие понимают под ним черт знает что или все сразу.
Причем дело доходит до обсурда.
Один под ДСЛ-нем начинает понимать все языки программирования которые кто-то прикрутил к какому то приложению (в том числе и жабаскрпит в броузерах).
Другой называет ДСЛ-ем наличие модели в приложении.
Третий видит ДСЛ в любом АПИ.
Короче полнейшая каша. С такой терминологической какофонией применять этот термин нельзя в принципе. Иначе любой разговор превратится в полную бессмыслицу.
N> Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.
Критерии различия очевидны. Но в виду того что в головах каша всем плевать на общее согласие. Все отстаивают правоту своих заблуждений
N>Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".
Фаулер не рассматривает отвлеченных тем. Он рассматривает то, что он сам считает (и называет) ДСЛ-ями.
По сему он привел ряд критериев которые позволяют назвать язык ДСЛ-ем (по его мнению). Я сними согласен.
Но к сожалению, они неформальны. Вот они:
Его мысль в том, что наличие одного из условий еще не делает язык ДСЛ-ем. Нужно сочетание факторов.
И я с этим категорически согласен.
N>Прикидка определения каждого из этих понятий:
N>* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
N>* специализированность — адаптирован в целом (в общих принципах) под названную цель
N>* специфичность — реализация запросов за пределами названной цели заметно усложнена
N>* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели
Опять какая-то каша. Ориентированность, специализированность и специфичность — это все из одной оперы.
VD>>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.
N>См. выше — должен быть не один критерий, а четыре.
Твои критерии вообще никуда не годятся. Критерии фаулера — годятся.
Язык с неограниченной выразительностью ДСЛ-ем быть не может, согласно этим критериям.
Таким образом полные по тьюрингу языки вполне могут быть ДСЛ-ями, если их тьюринг-полнота не дате писать что попало в любой области.
Зато язык не полный по тьюрингу и ориентированный на конкретную задачу — это уже точно ДСЛ.
И вообще, важно разделять ориентацию на предметную область, и ориентацию на задачу. ДСЛ ориентирован на одру конкретную задачу, а не на предметную область в широком понимании этого термина. Скажем императивный язык для бухгалтерии — это не ДСЛ. А вот язык запросов к документам — ДСЛ.
N>Во-во. Проблему он почувствовал, но выразить не супел.
Он то сумел. Просто кто-то кобенится и не хочет понять сказанного.
Я бы предпочел четкую терминалогию, и четкое разделение понятий. Язык 1Эс нужно отличать как от универсальных ЯОН-ов, так и от ДСЛ-ей. Это самостоятельный класс языков.
VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.
N>Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.
В том то и дело, что у нас дисскурссия возникает даже по крайним случаям. Есть не мало упертых товарищей которые называют ДСЛ-ями ВБА. А кое-то (весьма не глупый) вообще дофилософствовался до того, что подменил понятие "уровень языка" понятием "ДСЛ", а ДСЛ в его словах это любой язык относительно языка более низкого уровня.
Такие "знания" и такая терминология не дает возможность продуктивно обсуждать данную область.
Так что нужно сделать одно из двух:
1. Ограничить определение термина ДСЛ выделив независимые понятия в отдельные понятия и дав им названия (введя термины).
2. Придумать новые термины для подтипов ДСЛ-ей, если уж не удается прийти к консенсусу в п.1.
Вот регекспы и ВБА по-твоему ДСЛ-и?
Если, да, то нужно придумать новые термины для различения этих подвидов ДСЛ-ей.
Если нет, то для ВБА нужно придумать отдельный термин, а ДСЛ-ем называть только регекспы.
Для ВБА термин есть — скриповый язык встроенный в хост-приложение. А как нажвать класс ДСЛ-ей в который входят регексы, SQL и т.п.?