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

G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

[...]

G>Поэтому, все действительно практически успешные DSL на текущий момент имеют в качестве базы простейшие языки, с семантикой не сложнее раннего бейсика.

Вот тут — +100 под всем написанным.

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

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

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

А вот на этом пути надо не перегибать палку. В некоторых промышленных CAD-ах так старались добиться "нечеткого" и "естественного" синтаксиса, что получились языки с тысячами ключевых слов и десятитомными документациями.

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

N>>Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.
O> А вот на этом пути надо не перегибать палку. В некоторых промышленных CAD-ах так старались добиться "нечеткого" и "естественного" синтаксиса, что получились языки с тысячами ключевых слов и десятитомными документациями.

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

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

G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
Феерическая глупость.
Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.

G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.

G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
А что тут думать то?
Технических аргументов у тебя нет.
Одна демагогия.

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

G>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
WH>Феерическая глупость.
WH>Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.

Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?

G>>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
WH>Да правда что ли? SQL сплошной матан.

Формулировку "выбрать среди всех записей те, у которых тип Z" способен освоить много кто, но опять-таки речь не о тех языках.

WH> YACC, ANTLR и тп тоже один сплошной матан.

Адаптаторы и power users не пишут на Yacc.

G>>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
WH>А что тут думать то?
WH>Технических аргументов у тебя нет.
WH>Одна демагогия.

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

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

G>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
N>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
Ты прочитай, что Gaperton написал.
Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.

N>Формулировку "выбрать среди всех записей те, у которых тип Z" способен освоить много кто, но опять-таки речь не о тех языках.
О тех самых. Опять же читай то, что пишет Gaperton внимательно.
А пишет он бред.

Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

В основе SQL матан. Реляционная алгебра называется.
А то, что матан вдруг оказался простым в использовании это не удивительно.
Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.

WH>> YACC, ANTLR и тп тоже один сплошной матан.
N>Адаптаторы и power users не пишут на Yacc.
Чего?

N>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.
Да правда что ли?
На что тут можно возразить?
Все что можно сделать, это указать на бред.

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

G>>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
N>>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
WH>Ты прочитай, что Gaperton написал.
WH>Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.

Вот с этим и надо было спорить, а не с последствиями для очевидно другого предназначения — DSL для пользователей.

WH>А пишет он бред.

Нет, это ты не можешь отличить разговор в разных контекстах. Вообще напоминаешь героя одной истории:

Разговариваю с приятелем, который занимается каратэ. Он рассказывает о разных течениях и подвидах каратэ, показывает движения, в конце гордо заявляет:
— Так что эта классика — полное г#$но!
Из-за соседнего гаража выходит, покачиваясь, работяга с мутным взглядом, смотрит на нас и заявляет:
— Что ты сказал??? Да пошёл ты на#$% со своим передним приводом!

N>>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.
WH>Да правда что ли?
WH>На что тут можно возразить?
WH>Все что можно сделать, это указать на бред.

Вот и критикуй по сути — о пользе DSL для программистов, как совсем другого явления, чем DSL для пользователей.

Я поставил ему плюс именно за грамотные и интересные комментарии о DSL для пользователей — я раньше как-то не задумывался о том, почему большинство успешных из них так похоже на Basic.
То, что он начинает с категорического ограничения своего контекста и в принципе игнорирует мир DSL для программистов, разумеется, некорректно, но это специфика его манеры и как бы уже привычно.

А вот тема DSL для программистов — больше твоя тема. И если бы ты не пытался сразу одним словом определить весь мир (причём в 90% случаев это слово "бред"), тебя можно было бы читать с пользой.
А пока что с этим явные проблемы.

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

N>Я поставил ему плюс именно за грамотные и интересные комментарии о DSL для пользователей — я раньше как-то не задумывался о том, почему большинство успешных из них так похоже на Basic.

SQL похож на бейсик? Всевозможные внутренние list comprehension или query comprehension? UML? HTML? XAML? Может XSLT?

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

WH>В основе SQL матан. Реляционная алгебра называется.
WH>А то, что матан вдруг оказался простым в использовании это не удивительно.
WH>Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.

Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности. Через навигационные методы было бы проще и нагляднее или Linq.
Но есть простые задачи где SQL рулит. Нужно и то и другое. Нужны и DSL в составе ЯОН.

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

S> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.
Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.

S>Через навигационные методы было бы проще и нагляднее
Ну-ну.

S>или Linq.
Так я уже говорил, что линк это более правильный SQL.
Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.

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

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

S>> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.
WH>Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.
Ну писал огромное количество в свое время. Знаю о чем говорю. При том, что на любой структуре можно построить класс.
S>>Через навигационные методы было бы проще и нагляднее
WH>Ну-ну.
Есть куча мест где они и намного наглядне. Приходится писать кучу вложенных запросов просто для ипользовании вычисленных значений, что бы не было повторений и городить еще более сложный код для понимания, или разбивать текст на несколько строк, а потом их сшивать для получения результирующего запроса итд. И это еще в 1С где есть более менее нормальный конструктор "объектных" запросов.
S>>или Linq.
WH>Так я уже говорил, что линк это более правильный SQL.
WH>Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.
Ну так сколько времени то прошло. И Linq to EF нужно развивать. Кстати Linq пока хорош совместно с ObjectQuery. Так как у Linq есть ограничения в том числе и массовых изменений данных (Merge булки итд). И хотелось бы полностью избавиться от SQL.

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

S> Есть куча мест где они и намного наглядне. Приходится писать кучу вложенных запросов просто для ипользовании вычисленных значений, что бы не было повторений и городить еще более сложный код для понимания,
Ну, во-первых, вы правы. При разработке SQL вопросы повторного использования не рассматривались почти что никак. Поэтому в нём, в частности, нет функций высшего порядка. Да и вообще функций, аргументом которых являлось бы relation, нет.
Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".

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

WH>Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.

В некоторой мере DSL можно сделать на библиотеках и переопределении операций. Даже по твоей исходной ссылке непонятно, зачем там была DSL? Замени :- на какой-нить << и будет тебе щастье прямо из твоего языка программирования, будь то C# или C++. Там же просто декларация правил для решателя, и этой декларации не нужно мильон новых операторов для выражения всех поддерживаемых отношений.

Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.

Есть, конечно, момент кодогенерации, как в BLT (что есть тоже DSL на атрибутах), но этот момент прекрасно обыгрывается через post-build step.


WH>А пишет он бред.
WH>

WH>Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

WH>В основе SQL матан. Реляционная алгебра называется.

С какой радости малюсенький сугубо прикладной раздел теории мн-в стал разделом части фундаментальной математики?
Приплыли..


WH>А то, что матан вдруг оказался простым в использовании это не удивительно.

Принципы разложения по базисам или трюки с возможностью поиска решений в операторной области многие не понимают даже после 5-ти лет учебы. И простым это станет только если программист нарисует пользователю большую кнопку "сделать мне п-дато". Но DSL или реляционная алгебра здесь не при чем. На ее изучение отводится максимум 3-5 лекций и столько же практических занятий. ИМХО, копейки.


WH>Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.

Ну... сложные вещи даже на SQL просто не запишешь. Особенно когда речь пойдет о необходимости cross или outer join и понимании работы nullable-типов в этих случаях, если необходимо по таким выборкам производить ограничения. ИМХО, только простые вычисления будут выглядеть просто. Но это потому что происходящее на низлежащем уровне тоже довольно просто. И в теории аналогично не сложно. Т.е. я не вижу, где сложность теоретическая вдруг будет замаскирована простотой SQL. Единственный трюк, маскирующий сложность, это автоматическое преобразование условий существования (все операторы которого сводимы к одному из них) в продукцию, но ведь это детали реализации... человеку как раз удобней оперировать понятиями существования элемента в заданном им множестве и "тупая" наивная реализация может точно так же итерироваться по подмногжеству, как задано человеком, т.е. низлежащее преобразование условий существования в продукцию (т.е. переход от реляционного исчисления в реляционную алгебру) идет лишь эффективности ради.


WH>>> YACC, ANTLR и тп тоже один сплошной матан.

Опять промазал. Это прикладная наука формальных языков и их грамматик. Это не матан. Хотя задевает крылом области раздела традиционной математики при введении понятия мощности языков с помощью теоремы Кантора о мощности мн-в, но это так же не входит в матан.


WH>Все что можно сделать, это указать на бред.

Это от невладения информацией у читателя.

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

V>Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.
И никто такой код писать не будет. Ибо мусора много.

V>Есть, конечно, момент кодогенерации, как в BLT (что есть тоже DSL на атрибутах), но этот момент прекрасно обыгрывается через post-build step.
Это детали реализации.
В любом случае у этого подхода куча проблем.
Начина с того что этим трудно пользоваться заканчивая тем что интелисенса не будет.

V>С какой радости малюсенький сугубо прикладной раздел теории мн-в стал разделом части фундаментальной математики?
А что это?
Математика она и есть математика.

V>Приплыли..
Это точно.

V>Принципы разложения по базисам или трюки с возможностью поиска решений в операторной области многие не понимают даже после 5-ти лет учебы. И простым это станет только если программист нарисует пользователю большую кнопку "сделать мне п-дато". Но DSL или реляционная алгебра здесь не при чем. На ее изучение отводится максимум 3-5 лекций и столько же практических занятий. ИМХО, копейки.
Ох. Реляционная алгебра тут вообще не причем.
Я просто показал гапертону практически полезный ДСЛ в основе которого матан.
Тем самым опровергнув его утверждение.

V>Ну... сложные вещи даже на SQL просто не запишешь. Особенно когда речь пойдет о необходимости cross или outer join и понимании работы nullable-типов в этих случаях, если необходимо по таким выборкам производить ограничения.
Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.
Удачи.

V>Опять промазал. Это прикладная наука формальных языков и их грамматик. Это не матан. Хотя задевает крылом области раздела традиционной математики при введении понятия мощности языков с помощью теоремы Кантора о мощности мн-в, но это так же не входит в матан.
Ты бредешь. Теореммы есть? Есть. Доказательства есть? Есть.
Матан. По определению.

WH>>Все что можно сделать, это указать на бред.
V>Это от невладения информацией у читателя.
Во-во. Не читай про то, что не понимаешь. И тем более не комментируй.

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

WH>Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.

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


WH>Ты бредешь. Теореммы есть? Есть. Доказательства есть? Есть.
WH>Матан. По определению.

Матан — это не теоремы, это исследование ф-ий и их систем. В т.ч. дифференциальных и интегральных. Теория мн-в к матану не относится. "Узкие" прикладные разработки в рамках теории мн-в, типа реляционной алгебры или формальных языков и их грамматик — тем более не относятся.

WH>Во-во. Не читай про то, что не понимаешь. И тем более не комментируй.

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

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

WH>>Напиши это при помощи fopen, fread и fwrite. С ACID в полный рост.

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

select Manager.Name, OrderTotals.Amount 
from Manager 
inner join City on City.ID = Manager.CityID
inner join 
  (select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID) 
    OrderTotals on OrderTotals.ManagerID = Manager.ID
where City.Name like 'Н%'
order by 2 desc

V>Матан — это не теоремы, это исследование ф-ий и их систем.
Он про другой матан.

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

V>Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.

Дело не просто в записи. На DSL можно реализовать не только запись размерности величин, но и проверку на этапе компиляции, разрешена ли операция над этими величинами.

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

Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!

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

<оффтопик>
K>Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
В одной известной физической системе единиц как раз можно и даже возможно будет некий смысл. )))
</оффтопик>

А вообще я согласен. Именно в этом смысл DSL — ограничение возможностей.

K>Именно эту ситуацию способен разрулить DSL.

Только на самом деле действительно качественных dsl не так уж много. Мне с ходу sql, regexp, xslt, make в голову приходят — то, с чем часто имеем дело. Но это же капля в море. И инструментов для их проектирования в промышленных масштабах не видно.

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

K>Поясню. Например, в обычном коде имеются две переменные типа double — масса и температура. Простой язык программирования никак не запретит допустим сложить две эти переменные: с точки зрения компилятор типы double можно складывать. Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
На шаблонах С++ эту задачу можно решить довольно просто.
Показать, как или сам хочешь подумать?

K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
В случае с С++ это не проблема. Если в класс засунуть один double то там ничего кроме него не будет.

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

WH>На шаблонах С++ эту задачу можно решить довольно просто.
WH>Показать, как или сам хочешь подумать?

Я представляю в общих чертах, как это делается. Более того, есть готовые примеры:
http://www.rsdn.ru/forum/src/1824757.flat.aspx — C++.
http://www.rsdn.ru/forum/src/1823225.flat.aspx — Nemerle.
В своё время я очень заинтересовался этими двумя примерами.

Кстати, хотелось бы, чтобы нечто подобное было включено в стандартную библиотеку Немерла.


WH>В случае с С++ это не проблема. Если в класс засунуть один double то там ничего кроме него не будет.

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

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

K>Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.

Видимо, ты давно последний раз видел C++.
Если размерность значения определена в его типе, то достаточно легко получить и контроль во время компиляции (причём оно может, например, разрешить присвоить скорости произведение ускорения на время и в то же время запретить присвоение ей массы), и в то же время единственным данным внутри класса будет значение величины — например, типа double — и после оптимизации всё это выродится в простейшие операции со скаляром с плавающей точкой.

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

K>А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!

Для статически типизированного — да. Для динамически — нет.
Зависит именно от типизации.
Но можешь ли ты в DSL простым образом объявить новую размерность величины?
Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?

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

N>Для статически типизированного — да. Для динамически — нет.
N>Зависит именно от типизации.
N>Но можешь ли ты в DSL простым образом объявить новую размерность величины?
N>Вот потребовалось тебе что-то вроде паскалей в кубе на квадратный ампер. Объявишь?
Детский сад. Если уж С++ с этим справляется то ДСЛ с системой типов заточенной на это справится вообще не напрягаясь.

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

N>Видимо, ты давно последний раз видел C++.

Да, давно. Последние годы сижу на дотнете.


N>Если размерность значения определена в его типе, то достаточно легко получить и контроль во время компиляции (причём оно может, например, разрешить присвоить скорости произведение ускорения на время и в то же время запретить присвоение ей массы), и в то же время единственным данным внутри класса будет значение величины — например, типа double — и после оптимизации всё это выродится в простейшие операции со скаляром с плавающей точкой.

N>Попробуй сам (только на современных компиляторах, а не образца 95-го года) и удивись.

А это будет сильно проще этого примера: http://www.rsdn.ru/forum/src/1824757.flat.aspx? Или именно реализация на шаблонах имеется в виду?


N>Для статически типизированного — да. Для динамически — нет.
N>Зависит именно от типизации.

Не, не, — динамическая типизация идёт лесом. Только статика, только проверки в компайл-тайме по максимуму.

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

WH>> YACC, ANTLR и тп тоже один сплошной матан.

N>Адаптаторы и power users не пишут на Yacc.

Однако power users обожают регвыры, куда как более матанистые.

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

WH>>> YACC, ANTLR и тп тоже один сплошной матан.
N>>Адаптаторы и power users не пишут на Yacc.
O>Однако power users обожают регвыры,

Слово-то какое.

O> куда как более матанистые.

Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.
Чтобы перейти на уровень, где грамматика проще регулярных выражений, надо выучить нехилый пласт теории.

BTW, типичное регулярное выражение это даже не grep/posix-style. Это BASIC-style (это там, где '#' значит цифру, а '%' любую строку).

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

O>> куда как более матанистые.

N>Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.

А не надо описывать грамматики с конфликтами. Не надо пользоваться всякими устарелыми LALR — есть прекрасный, человечный, понятный интуитивно LL(n), выразимый множеством простых и естественных способов, включая и ad hoc рекурсивный рукописный код. И вот это как раз намного прозрачнее и намного менее матанисто чем даже самый простой регвыр.

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

Вот честно — никогда этой самой теорией не владел, забыл все сразу за ненадобностью. А парсеры писать умудряюсь. Да, парсер какого либо хитровыгнутого языка вроде C++ я бы с ходу не написал, ну так надо быть садистом и мизантропом чтобы для DSL такой синтаксис выдумывать. Если синтаксис DSL не ложится на LL(1), то синтаксис плохой.

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

WH>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.

Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.

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

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

WH>>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.
O> Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.
Я с этим не спорю.
Но прочитай, что он сказал.

G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

Он явно гонит. Что я и продемонстрировал.

O>Я согласен с вашим оппонентом, что dsl должны быть тупыми. Вся сложность должна прятаться в их реализации. И есть множество способов сокращения даже этой сложности — если использовать dsl для реализации dsl, и если использовать более простые или более общие dsl в качестве целевого языка при компиляции новых dsl. Такаямногоуровневая структура позволяет избавляться от сложности на всех этапах.
Подписываюсь под каждым словом.
И я тебе больше скажу: Именно разработкой такой системы я и занимаюсь.

Вот только он не это сказал.
Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
Читай то, что написано, а не то, что ты хочешь прочитать.
И имей в виду гапертон талантливый болтун, который имеет убеждать других в том, что он что-то знает. Но это не так. Ибо он слил в 100% технических споров.

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

WH>Вот только он не это сказал.
WH>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
WH>Читай то, что написано, а не то, что ты хочешь прочитать.

Да, мне раза три перечитать пришлось. Вижу, что был не прав.

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

WH>>Вот только он не это сказал.
WH>>Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
WH>>Читай то, что написано, а не то, что ты хочешь прочитать.
O> Да, мне раза три перечитать пришлось. Вижу, что был не прав.
В этом и есть единственный талант данного персонажа.
Он умеет говорить бред, так что у окружающих создается впечатление, что он сказал что-то умное.

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

G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

Это очень спорное утверждение.

Квалификация может требоваться и очень высокая, а вот решение будет более простым для достаточно квалифицированного специалиста.

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

Так что цель создания ДСЛ — упростить решение задачи. А рассуждения про квалификацию здесь излишние (если не сказать некорректны).

G>Еще один пример

А где был первый пример?

G>из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.

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

G> Это для них в игровую платформу внедряют LUA. Цель — исключить необходимость затратного общения между гейм-аналитиками и программистами при реализации AI, пусть аналитики справляются сами.

Луа — ЯОН. Весь смысл его применения в игровых движках — сделать их отладку более интерактивной.

Ну, и никакие аналитики им пользоваться не могут. Да и что за зверь такой этот аналитик? Может дизайнер уровней?

G>Поэтому, все действительно практически успешные DSL на текущий момент имеют в качестве базы простейшие языки, с семантикой не сложнее раннего бейсика. 1С только один из немногих примеров.

Подмена предмета обсуждения дететкетд. Луа — ЯОН. Все выводы сделанные на предположении, что Луа — это ДСЛ ничтожны.

Ну, и 5 копеек про "с семантикой не сложнее раннего бейсика":

Класс языка:
мультипарадигмальный:
скриптовый,
императивный,
функциональный,
объектно-ориентированный (прототипный)

(с) Википедия.

Ничё так описание для языка не сложнее раннего бэйсика. Так и вижу себе реализацию GoSub на мета-таблицах.

G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple.

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

G>Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.

Ага. И видимо после перехода с Лиспа на ВБА скрипты чудесным образом превратились в ДСЛ.

Там что Лисп, что ВБА используются для автоматизации. А сами языки универсальны в доску.

G>И это закономерно, что базовая семантика этих языков тупа до безобразия.

Чё за базовая семантика такая? Чем она у Лиспа острее? Его семантику можно на любом языке за денек воспроизвест\и.

G>Влад, ты в каком-то своем странном мире живешь, реально.

Влад, ты в каком-то своем странном мире живешь, реально.

VD>>1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.

G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)

Что добиться то? Там основные заслуги в организации франчейзи, сети сбыта, маркетинге и т.п. Как программный продукт 1Эс скорее всего уступит какому-нибудь Парусу с огромным счетом.

И на хрена мне этого добиваться то? У меня свои "игрушки".

Все же прокомментирую, хоть и не собирался.

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

G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.

У вас абсолютно неверное представление о целях создания DSL. В первую очередь DSL нужны самим программистам. Чаще всего — тем же, кто их и создает, то есть, как правило делаются они для себя, и только потом уже для других.

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

Посмотрите, например, на исходный код LLVM — там этих DSLей довольно много, в том числе и очевидные внешние DSL (TableGen, на самом деле это даже не один язык а целая их коллекция). И они не для "программистов с на порядок меньшей квалификацией" сделаны, а для самих разработчиков LLVM, которые, полагаю, профессиональнее нас всех вместе взятых. Просто глупо это, правила instruction scheduling писать на "языке общего назначения", очень много однотипного табличного кода получится. А вот сгенерить этот код из полудекларативного описания — легче легкого. В результате добавление поддержки новых архитектур в LLVM становится тривиальной задачей. Если бы они еще и осилили DSL для упрощения pattern matching в C++ сделать, то избавились бы и от многокилометровых лесенок из if-ов (например, в instcombine pass), но тут скорее не на разработчиках вина, а на недостатках языка C++.

Про gcc и говорить не буду, там просто Лисп внутри, а на Лисп у здешней публики, как я уже догадался, сильнейшая аллергия.

G>Еще один пример из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты.

Насколько я знаком с игровой индустрией, пишут их все же таки программисты. А Lua используется потому, что это офигенно удобный динамический язык, и разработка игровой логики на нем идет на порядки быстрее, чем если бы это был статически типизированный монстр с раздельной компиляцией вроде C++.

G>Еще примеры? Системы компьютерной алгебры. Maltab. Maple. Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.

Самая популярная такая система — Matematica. У меня язык не повернется сравнивать ее семантику с бейсиком, хотя пользуются Математикой далеко не программисты. Это функциональный язык, построенный на правилах переписывания, ни разу не бейсик.

R — тоже функциональщина, и тоже очень популярен среди не-программистов. Бейсиком там и не пахнет.

G>И это закономерно, что базовая семантика этих языков тупа до безобразия.

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

Некоторые по этому пути вообще очень далеко зашли. В системе Stata по сути два языка — один, внешний — для конечных пользователей, финансистов там всяких, которые программированием заниматься вообще не должны, и второй (в который первый язык тупо транслируется) для "power users".

G> Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

Про Mathematica знает намного больше людей, чем про Lua. А уж матана там хватило бы на зверское убиение трех курсов физтеха.