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

I>>Мне этот дсл ровно ничего не даёт, потому я обхожусь без него Причины простые — его дизайнил непойми кто. В говнобиблиотеке проще разбираться что в таких вот говнодсл. Не ясно, откуда возьмется должное количество дсл-архитекторов, что бы на каждый проект хватило.

Z>Наследование используют? Оно покритичнее к ошибкам будет.

Ну и что ? При современных средствах рефакторинга и тд фиксится за время много меньшее времени написания.

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

Z>А они точно регулярные грамматики парсят?

Точно.

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

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

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

Z>>> a.Insert(b) и insert b into a

K>>Я именно такие примеры имел в виду, когда писал ранее о плохой подаче информации о макросах и дслях. Большинство обучающих примеров сделаны именно так: сперва пишется некая простая функция (Insert()), потом она заменяется на макрос (insert into). В итоге читатель не видит никакой разницы, уменьшения кода не происходит, понимание не улучшается.

_DA>Давайте я покажу пример чуть сложнее из нашего проекта. Задание бизнес-логики, объявление функционала в виде композиции других функционалов.

ИМХО, ваш пример в точности соответствует тому, что вы хотели опровергнуть.
Т.е. "никакой разницы, уменьшения кода не происходит, понимание не улучшается".

Мало того, мне код на джаве более-менее понятен, а DSL...

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

_DA>Давайте я покажу пример чуть сложнее из нашего проекта. Задание бизнес-логики, объявление функционала в виде композиции других функционалов.
_DA>java:
_DA>

_DA>LP entryPrice = addJProp(null, "entryPrice", "Цена входная", and(false), price, 1, 3, quantity, 1, 2, 3);
_DA>

_DA>DSL:
_DA>

_DA>entryPrice 'Цена входная' (invoice, stock, sku) = price(invoice, sku) IF quantity(invoice, stock, sku);
_DA>

1. Букв меньше не стало.
2. Понятность? Да куда там! Читать просто как текст — понятнее, но если приспичит исправить — сразу куча вопросов. Понятнее было бы тупо завернуть длинный список параметров в пару иерархий ParamObject, типа как-то так:

entryPrice = addJProp('Цена входная', new Price(...), new IfQuantity(...))

Вывод: низачот. Впрочем, я могу чего-то недопонимать (в частности, параметр "entryPrice" в первом примере указывает на наличие доп. сложности, мною не учтённой: динамика/рефлексия/хз что).

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

M>>У нас на работе используется три DSLя.
AVK>Бесполезно (я все ждал когда спор перейдет в эту плоскость).
К которым как мы выяснили он никакого отношения не имеет.

AVK>AVK вон последнее время большую часть времени занят написанием DSL, а все теоретик.
Те ты намеренно распространяешь заведомо ложные сведения о том, что в случае с ДСЛ его нельзя немного подпилить?
С какой целью?

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

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

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

K>>Пусть это не тянет на DSL, но тянет на примеры того, где макросы могут сильно помочь, вводя проверки формата на этапе компиляции.

AVK>А при чем тут макросы?

Потому что макросы являются основой для создания DSL. Строка форматирования — своего рода микро-(нано-)DSL — это язык формата.


K>>Глянул сейчас форум Regular Expressions на MSDN — ни одного неотвеченного вопроса.

AVK>При чем тут неотвеченные вопросы?

На все вопросы даны ответы — значит много людей способны разобраться в языке регулярок, значит найдётся много людей способных разобраться в новом языке.
Я тоже признаю, что каждый раз, как приходится в очередной раз сочинять регулярку, я заглядываю в документацию. Но это потому, что редко приходится это делать. Если на длительное время заброшу C#, потом тоже полезу в доку. Без доки я и сейчас не скажу, как именно используется stackalloc, по той же причине: использовал его в последний раз очень давно.

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

K>Я тоже признаю, что каждый раз, как приходится в очередной раз сочинять регулярку, я заглядываю в документацию. Но это потому, что редко приходится это делать. Если на длительное время заброшу C#, потом тоже полезу в доку. Без доки я и сейчас не скажу, как именно используется stackalloc, по той же причине: использовал его в последний раз очень давно.
Точно так же почти никто из присутствующих не скажет без документации как использовать CreateFile из WinAPI.
Чего уж говорить про доморощенные библиотеки, которые никто за приделами конторы никогда не видел.

Но дело в том что у них просто цель любой ценой доказать что у ДСЛ есть куча проблем которых нет у библиотек.

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

_DA>>Давайте я покажу пример чуть сложнее из нашего проекта. Задание бизнес-логики, объявление функционала в виде композиции других функционалов.
_DA>>java:
_DA>>

_DA>>LP entryPrice = addJProp(null, "entryPrice", "Цена входная", and(false), price, 1, 3, quantity, 1, 2, 3);
_DA>>

_DA>>DSL:
_DA>>

_DA>>entryPrice 'Цена входная' (invoice, stock, sku) = price(invoice, sku) IF quantity(invoice, stock, sku);
_DA>>

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

D>1. Букв меньше не стало.
Я к этому не стремился в данном случае. Эти две строки не эквивалентны, но это действительно как было и как стало. Можно было на DSL написать

entryPrice 'Цена входная' = price($1, $3) IF quantity($1, $2, $3);

Это уже ближе к строке на джаве, но в продакшен коде так никто писать не будет.


D>2. Понятность? Да куда там! Читать просто как текст — понятнее, но если приспичит исправить — сразу куча вопросов.
Мне вот интересно, а что было понятно из строчки на джаве, если бы я не привел строку на DSL? Сразу стало понятно, что после строковых констант идет описание выражения в польской нотации? Сразу было понятно, что price — это функционал с двумя параметрами, которому передаются на вход первый и третий параметр создаваемого функционала?
Насчет исправлений предполагается, что те, кто будут на этом DSL писать, будут все-таки его знать и иметь возможность прочитать все интересующее в документации.

D>Понятнее было бы тупо завернуть длинный список параметров в пару иерархий ParamObject, типа как-то так:

D>

D>entryPrice = addJProp('Цена входная', new Price(...), new IfQuantity(...))
D>

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

LP entryPrice = addJProp(null, "entryPrice", "Цена входная", and(false).map(price.map(1, 3), quantity.map(1, 2, 3));

Во-вторых, можно заменить порядковые номера параметров на какой-то аналог именованных параметров. Допустим, мы сделали вот так:

LP entryPrice = addJProp(null, "entryPrice", "Цена входная", PARAMS("invoice", "stock", "sku"), and(false).map(price.map("invoice", "sku"), quantity.map("invoice", "stock", "sku"));

Теперь вспомним код на DSL:

entryPrice 'Цена входная' (invoice, stock, sku) = price(invoice, sku) IF quantity(invoice, stock, sku);

У нас после перехода на DSL разработка, на мой взгляд, существенно ускорилась и упростилась. Более того, код на DSLе пишут и бизнес-аналитики, не имеющие технического образования, и уж тем более, не знающие java. Правда, объяснить, почему разработка ускорилась, каким-то одним примером точно не получится.

D>Вывод: низачот. Впрочем, я могу чего-то недопонимать (в частности, параметр "entryPrice" в первом примере указывает на наличие доп. сложности, мною не учтённой: динамика/рефлексия/хз что).

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

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

M>>Т.е. разработчик скорее болен чем то уникальным . если интерфейс назвать магическим DSL то он может отделить реализацию , а на уровне интерфейса к библиотеке нет ? И по такому анекдотичному примеру ты строишь предположеничя ?
WH>Начнем с того что интерфейс в терминах C# или жабы это УЖЕ детали реализации которые часто просто не нужны.

В контексте разговора это абсурд. Т.е. для DSL интерфейс не нужен и можно писать "делай что мне надо" в каждой программе? Для меня не звучит разумно.

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

_DA>Правда, объяснить, почему разработка ускорилась, каким-то одним примером точно не получится.

ИМХО если не удается внятно объяснить, чем DSL лучше кода на джаве, то что то здесь не то.

M>>>У нас на работе используется три DSLя.
AVK>>Бесполезно (я все ждал когда спор перейдет в эту плоскость).
WH>К которым как мы выяснили он никакого отношения не имеет.

Я с ними работаю, и привожу конкретные примеры. В отличие от тебя.

У меня сейчас нет исходников
У меня нет примеров
На моем компьютере все работает

Ага-ага. Что-то мне подсказывает, что к DSLям ты имеешь еще меньшее отношение, чем я. Иначе за последние два года пафосного вещания про них ты бы откопал и примеры и исходники. Но их как не было, так и нет и не предвидится.

M>>Ну да, из текста, который говорит: из 5к строчек мы получаем 50к сгенеренного кода ты делаешь далеко идущий вывод, что библиотека, существовашая до этого, имела 50 к кода. Ну-ну.
WH>Нет. Я делаю вывод о том, что без ДСЛ у тебя было бы не 5К строк прикладной логики, а 50К.

Неверный вывод.

WH>>>1)Если ДСЛ придется изменить, это потребует на порядок другой меньше работы, чем изменение интерфейса библиотеки, которая делает то же самое.
M>>Доказательств кроме «я, у меня» ты так и не смог предоставить ни одного.
WH>А то, что это доказано по твоей ссылке не считается?

Что именно доказано по моей ссылке?

WH>Ведь если бы у тебя было бы 50К строк на эрланге, то при изменении библиотеки тебе бы пришлось все их перелопатить.

По моей ссылке написано, что компилятор генерит столько-то строк. Из этого никак не следует, что в изначальной библиотеке было 50к строк. Это во-первых.
Во-вторых, изменив DSL нам все равно пришлось перелопачивать все места, где он используется.

WH>>>2)Многие вещи, которые требуют изменения интерфейса библиотеки, не требуют изменения ДСЛ.
M>>Это ты тоже кроме как «я, у меня» аргументировать не смог.
WH>Опять же читай свою ссылку.
WH>Видишь, тут нет ни одной завязки на реализацию.
WH>Теперь сравни это с тем, что из этого кода генерируется.

Ты банально не представляешь себе библиотеки в виде черных ящиков?


M>>Именно потому, что компилятор выдавал сообщения об ошибке, приходилось перелопачивать все места, где использоввался этот DSL.
WH>Ты так говоришь как будто сообщения компилятора это что-то плохое.

Что ты там говорил? При изменении DSL надо будет менять что-то там меньше? Нам пришлось править все места, где этот DSL использовался. Как-то твоя сказочка про «править меньше» не сработала.

M>>Мегаумному Вульфхаунду, который никогда не включает дурачка, не приходит в голову, что замена синтаксиса «a PLUS b» на «a + b» в DSLе приведет к тому, что надо будет менять все места, где эта конструкция вызывается?
WH>А я хотя раз сказал, что не придется?
WH>Всё что я говорю, что то же самое придется делать и в случае с библиотеками.
WH>Но из-за того что кода будет на порядок больше придется заниматься этим в намного больших объемах.

Итак, DSL используется в сотне мест, вызов библиотеки используется в сотне мест.

WH>А некоторые изменения, которые я делал в реализации ДСЛ, с библиотекой я бы никогда не сделал. Ибо пришлось бы выкинуть весь код. А в случае с ДСЛ пришлось только перекомпилировать написанный на нем код.

Дададада. Мы тебе верим, потому что ты не способен привести ни единого примера, а опыт других людей — ложь. И то, что можно изменять библиотеки, не изменяя интерфейса библиотеки или не выкидывая весь код, — это тоже ложь. Естественно, ибо also sprach Wolfhound ©™.

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

M>В контексте разговора это абсурд. Т.е. для DSL интерфейс не нужен и можно писать "делай что мне надо" в каждой программе? Для меня не звучит разумно.
Это факт.
Интерфейс ДСЛ это синтаксис и семантика.
И они не содержат никаких завязок, на то во что этот ДСЛ будет скомпилирован.

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

M>Я с ними работаю, и привожу конкретные примеры. В отличие от тебя.
Которые подтверждают мои слова и опровергают твои.

M>Ага-ага. Что-то мне подсказывает, что к DSLям ты имеешь еще меньшее отношение, чем я. Иначе за последние два года пафосного вещания про них ты бы откопал и примеры и исходники. Но их как не было, так и нет и не предвидится.
Так было. И не раз.
Только ты повесил на них ярлык, что это типа не промышленные ДСЛ.

А исходников тех ДСЛ код, на которых исполнился в продакшене сотни миллионов, если не миллиарды раз у меня сейчас просто нет.

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

_DA>Мне вот интересно, а что было понятно из строчки на джаве, если бы я не привел строку на DSL?

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

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

_DA>Сразу стало понятно, что после строковых констант идет описание выражения в польской нотации? Сразу было понятно, что price — это функционал с двумя параметрами, которому передаются на вход первый и третий параметр создаваемого функционала?

Чего? "Сразу понятно", угу. Может я тупой, но лично мне вся DSL-строка кажется полностью контр-интуитивной. Чего она делает, я до сих пор не понимаю.

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

WH>>Нет. Я делаю вывод о том, что без ДСЛ у тебя было бы не 5К строк прикладной логики, а 50К.
M>Неверный вывод.
Почему?

M>Что именно доказано по моей ссылке?
То, что код на ДСЛ на порядок меньше и как следствие исправить его на порядок проще, чем код на библиотеке.

M>По моей ссылке написано, что компилятор генерит столько-то строк. Из этого никак не следует, что в изначальной библиотеке было 50к строк. Это во-первых.
Так я и не про библиотеку говорю.
И я тебе уже не раз это сказал.
Я говорю про тот код, который будет написан с использованием библиотеки.

M>Во-вторых, изменив DSL нам все равно пришлось перелопачивать все места, где он используется.
А при изменении библиотеки тебе бы не пришлось переписывать все места, где эта библиотека используется?
А про то, что таких мест тупо в 10 раз больше чем случае с ДСЛ ты не забыл?
Те в случае с библиотекой процесс изменения прикладной логики потребовал бы минимум в 10 раз больше ресурсов.

M>Ты банально не представляешь себе библиотеки в виде черных ящиков?
Если мы говорим про изменения синтаксиса и семантики ДСЛ то интерфейс библиотеки которая делает то же самое будет изменен гарантировано.

M>Что ты там говорил? При изменении DSL надо будет менять что-то там меньше? Нам пришлось править все места, где этот DSL использовался. Как-то твоя сказочка про «править меньше» не сработала.
Если бы вы использовали библиотеку, то у вас было бы в 10 раз больше таких мест.
И вы убили бы в 10 раз больше времени на то чтобы их исправить.

M>Итак, DSL используется в сотне мест, вызов библиотеки используется в сотне мест.
По твоей ссылке кода получается в 10 раз больше.
Так что умножай на 10.

M>Дададада. Мы тебе верим, потому что ты не способен привести ни единого примера, а опыт других людей — ложь.
Опыт? Да ты сам себе противоречишь.
Я могу показать тебе генератор парсеров, в котором я это проделал.
Легче станет?
Хотя я уже знаю твой ответ: Это не промышленный ДСЛ и ничего не доказывает.

M>И то, что можно изменять библиотеки, не изменяя интерфейса библиотеки или не выкидывая весь код, — это тоже ложь. Естественно, ибо also sprach Wolfhound ©™.
Если тебя послушать то получается, что библиотеки это всё могут, а ДСЛ нет? Я тебя правильно понял?
При этом объективно ДСЛ это могут лучше.
Просто по тому, что они не содержат никаких завязок на реализацию. А в тех случаях когда не получается прикладного кода на порядок другой меньше и исправить его на порядок другой проще.

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

WH>Интерфейс ДСЛ это синтаксис и семантика.

Интерфейс библиотеки это только семантика.

WH>И они не содержат никаких завязок, на то во что этот ДСЛ будет скомпилирован.

И она не содержит никаких завязок, на то как эта библиотека будет реализована.

M>>Я с ними работаю, и привожу конкретные примеры. В отличие от тебя.
WH>Которые подтверждают мои слова и опровергают твои.

Твои слова они не подтверждают.

M>>Ага-ага. Что-то мне подсказывает, что к DSLям ты имеешь еще меньшее отношение, чем я. Иначе за последние два года пафосного вещания про них ты бы откопал и примеры и исходники. Но их как не было, так и нет и не предвидится.
WH>Так было. И не раз.

Где. Хоть одну ссылку. Потому что только в этом топике, показательно, что ты юлишь, как уж на сковороде, лишь бы не приводить ни одного примера вообще: http://rsdn.ru/forum/philosophy/5019509.1

Автор: AlexRK
Дата: 04.01.13

WH>А исходников тех ДСЛ код, на которых исполнился в продакшене сотни миллионов, если не миллиарды раз у меня сейчас просто нет.

Дадада. Ох уж эти сказки, ох уж эти сказочники ©

WH>>>Нет. Я делаю вывод о том, что без ДСЛ у тебя было бы не 5К строк прикладной логики, а 50К.
M>>Неверный вывод.
WH>Почему?

А подумать?

M>>Что именно доказано по моей ссылке?
WH>То, что код на ДСЛ на порядок меньше и как следствие исправить его на порядок проще, чем код на библиотеке.

Если код с использованием библиотеки выглядит как addRule(a,b,c), а код на DSL как rule a b c, то править одинаково.


M>>По моей ссылке написано, что компилятор генерит столько-то строк. Из этого никак не следует, что в изначальной библиотеке было 50к строк. Это во-первых.
WH>Так я и не про библиотеку говорю.
WH>И я тебе уже не раз это сказал.
WH>Я говорю про тот код, который будет написан с использованием библиотеки.

Из этого так же никак не следует, что его будет написано 50к строк такого кода.

M>>Во-вторых, изменив DSL нам все равно пришлось перелопачивать все места, где он используется.
WH>А при изменении библиотеки тебе бы не пришлось переписывать все места, где эта библиотека используется?
WH>А про то, что таких мест тупо в 10 раз больше чем случае с ДСЛ ты не забыл?

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

WH>Те в случае с библиотекой процесс изменения прикладной логики потребовал бы минимум в 10 раз больше ресурсов.

Лож ©

M>>Ты банально не представляешь себе библиотеки в виде черных ящиков?
WH>Если мы говорим про изменения синтаксиса и семантики ДСЛ то интерфейс библиотеки которая делает то же самое будет изменен гарантировано.

И?


M>>Что ты там говорил? При изменении DSL надо будет менять что-то там меньше? Нам пришлось править все места, где этот DSL использовался. Как-то твоя сказочка про «править меньше» не сработала.
WH>Если бы вы использовали библиотеку, то у вас было бы в 10 раз больше таких мест.
WH>И вы убили бы в 10 раз больше времени на то чтобы их исправить.

Лож ©


M>>Итак, DSL используется в сотне мест, вызов библиотеки используется в сотне мест.
WH>По твоей ссылке кода получается в 10 раз больше.
WH>Так что умножай на 10.

Лож ©

M>>Дададада. Мы тебе верим, потому что ты не способен привести ни единого примера, а опыт других людей — ложь.
WH>Опыт? Да ты сам себе противоречишь.
WH>Я могу показать тебе генератор парсеров, в котором я это проделал.

А, да. Единственный DSL, из «десятков каждый день», который ты способен предоставить. Видимо потому что это — единственный DSL, который хоть как-то подтверждает твои слова. Или единственный DSL, который ты вообще написал. Или единственный, который вообще используется.

M>>И то, что можно изменять библиотеки, не изменяя интерфейса библиотеки или не выкидывая весь код, — это тоже ложь. Естественно, ибо also sprach Wolfhound ©™.
WH>Если тебя послушать то получается, что библиотеки это всё могут, а ДСЛ нет? Я тебя правильно понял?

Нет, неправильно

WH>При этом объективно ДСЛ это могут лучше.

О да, объективно. Объективные вещи имеют в основе аргументацию лучше, чем «лож», «неправда», и «у меня на компьютере работают».

WH>Просто по тому, что они не содержат никаких завязок на реализацию. А в тех случаях когда не получается прикладного кода на порядок другой меньше и исправить его на порядок другой проще.

DSL перестал быть прикладным кодом? Это в какой момент?

M>>Если у тебя есть возможность менять компилятор DSL, значит у тебя есть возможность менять библиотеку Почему внезапно ты пишешь, что библиотеку менять сложнее или нельзя ее поменять без изменения интерфейса?
WH>1) Кода на ДСЛ будет на порядок другой меньше.

Далеко не факт. Зависит как от библиотеки так и от DSLя

WH>а. Нужно будет переделать меньше клиентского кода.

Далеко не факт

WH>б. Компилятор ДСЛ может давать внятные сообщения с подсказками.

Может, но это не обязательно. Более того, компилятор может давать не менее внятные сообщения и для библиотеки

WH>в. Можно просто сделать рефакторинг который будет переделывать старый код в новый. Если конечно кода очень много.

Внезапно можно просто сделать рефакторинг для вызовов библиотеки. В частности потому что существующие средства это уже позволяют. Откуда возьмутся средства для простого рефакторинга DSL известно только известным сказочникам.

WH>2) ДСЛ намного лучше скрывает реализацию. Просто по тому что вычислительная модель языка на котором написана библиотека не путается под ногами.

Как там было в примерах? a.Insert(b) против insert b into a? Каким образом реализован этот самый insert вызывающего не волнует от слова вообще. Где там что путается под ногами неизвестно.

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

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

_DA>>Правда, объяснить, почему разработка ускорилась, каким-то одним примером точно не получится.

AVK>ИМХО если не удается внятно объяснить, чем DSL лучше кода на джаве, то что то здесь не то.

Я с этим согласен, но я не говорил, что вообще не смогу объяснить. Просто, чтобы объяснять преимущества конкретного DSL, нужно сначала объяснить domain. Мы делаем платформу для построения бизнес-приложений с довольно своеобразной концепцией, базисом, терминологией. Рассказать об этом в нескольких сообщениях на форуме у меня вряд ли получится. Нужны презентации, туториалы, которых сейчас либо нет, либо они уже устарели.
DSL нам позволил отобразить все наши концепции напрямую в более-менее лаконичные синтаксические конструкции, хорошо понимаемые при условии понимания нашей платформы. Код же на джаве без этого понимания выглядит, на мой взгляд, такой же абракадаброй, но только еще со своими синтаксическими и логическими ограничениями.