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

VD>>Это вопрос образования и материалов по теме.

AVK>Это еще и вопрос нужного склада ума.

Несомненно. Кухарка не может проектировать ПО. Но тот кто может проектировать ПО, может выделять (придумывать) ДСЛ-и.

В сотый раз повторяю: главное в ДСЛ-е — модель.

Мало людей может придумать модель для задачи?

AVK>Я не спрашиваю про готовый DSL.

А я не отвечаю про готовый DSL.

AVK>Пусть это будет не совсем корректное решение, мне интересно именно на идею посмотреть.

Идею чего?

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

AVK>А я с этим и не спорю.

Дык с чем ты тогда споришь то? Мы же вроде уже выяснили, что хотя не все могут, но многие могли бы. Вот ты, например, мог бы.

VD>>Кроме того идея ДСЛ-я еще дает в руки возможность генерировать код

AVK>Это можно и без DSL делать в определенной степени.

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

VD>>Тоже не совсем так. ДСЛ могут быть простыми. Такие ДСЛ-и можно давать и конечным пользователям. Не всем, но все же.

AVK>Ну вот мне очень хотелось бы посмотреть на то, как мог бы выглядеть DSL для бизнес логики типичной ERP системы (1С, как мы поняли, не DSL). Не нравится мой пример — можно любой другой взять, даже гипотетический. Но что то ответа нет. А именно это интересно, инструментарий для реализации уже вторичен.

Ну, предположим можно придумать DSL который бы позволил бы описать некие правила контроля конкретного документа. Что-то вроде:

Sum > 10000 => Operator mast be Supervisor 
Client is PreferredPartner => UsePrice(3)

Далее помещаем эти правила в файл и позволяем пользователям изменять его. Ну, и используем эти правила при сохранении документа.

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

VD>>Простой пример. Многие пользователи спокойно правят конфигурационные файлы приложений. А ведь это и есть ДСЛ-и!

AVK>Если ьы мне был интересен DSL для конфигураций, я бы так и написал.

А нет никакой разница для чего ДСЛ. Проме того почти все ДСЛ используются для конфигурации. Скажем грамматика — это конфигурация для парсера. Описание КА — это конфигурация для машины состояний. Бизнес-правила — это конфигурация для движка проверки бизнес-правил.

AVK>Ну так приводи пример, раз миф. С бизнес-спецификой ты, вроде как, в какой то степени знаком.

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

VD>>Совсем ужасны.

AVK>Так укажи на ужасы в приведенном коде. Именно их я и хочу обсудить.

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