Здравствуйте, WolfHound, Вы писали:
WH>Всё по тому, что через интерфейс библиотеки всегда просачивается реализация. А через ДСЛ нет.
Т.е. разработчик скорее болен чем то уникальным . если интерфейс назвать магическим DSL то он может отделить реализацию , а на уровне интерфейса к библиотеке нет ? И по такому анекдотичному примеру ты строишь предположеничя ?
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[25]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Но и не легче.
M>>Это и есть реверс-инжиниринг WH>Те никаких проблем по сравнению с библиотекой как мне тут пытаются втирать.
Проблемы есть. Если библиотека более-менее отражает логику бизнес-процесса или просто логику программы, то компилятор отразит что? Правильно, помимо собственно бизнес-логики, там будет еще полно ненужного никому парсинга, разбирания на токены, восстановления/установления контекста, отражения DSL на внутреннее представление, а того представления на собственно логику и т.д. и т.п. Причем в зависимости от компилятора и кривизны рук компиляторостроителя это может быть как кашей, так и не кашей.
M>>Да-да-да. Сказки про панацею мы слушаем уже который код. Не интересно. WH>Это не сказки. Это УЖЕ работает.
Здравствуйте, Mamut, Вы писали:
M>У нас на работе используется три DSLя.
К которым ты не имеешь никакого отношения.
M>Причем не в академическом проекте, который существует только в бурных подростковых фантазиях его авторов, а в реальной коммерческой системе, приносящей неиллюзорные деньги.
Что наступил на мозоль?
Да и мои ДСЛ, в том числе в реальных системах работают.
M>О двух из них я немного говорил: http://rsdn.ru/forum/philosophy/5017200.1
. Изменение этих DSLей или изменение их поведения занимает по трудоемкости не меньше, чем изменение и обновление любой другой библиотеки в проекте.
Ох, как ты подставляешься то...
Из твоей презентации.
● Once, as a very young company, Klarna had all the business logic in Erlang code
● Management/Finance could not read it
● Developers required both to change logic and to explain the current logic
● Code upgrade necessary for all changes
● No trace of how decisions were made
Ровно то, что я говорю.
● From an input file of 5 K lines of rules
● To 50 K lines of (prettyprinted) Erlang
И даже размер разбухания кода как я и говорю на порядок. И это не самый запущенный случай.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[27]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
I>А с языком именно это и надо, потому что мало людей которые скажем теорию категорий на раз понимают.
Я уже вообще не понимаю, что ты сказать пытаешься.
Причем тут теория категорий?
I>ИДЕ с нынешними возможностями или ИДЕ того времени когда будет актуальным этот C#10 ?
Фичи ИДЕ очень близки к насыщению. Ничего революционного не видно.
Но даже если и будет, то я не сомневаюсь что поддержим.
Часть фичей, как я уже говорил, будет появляться вообще без строчки кода. Для других придется что-то написать, но это что-то будет на порядок меньше чем нужно писать сейчас.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
WH>>У меня сейчас просто нет тех исходников. ARK>Я не прошу исходники, я прошу демонстрационный пример.
Какой пример? Мне что его из пальца высосать?
ARK>Кстати, я вполне могу представить ситуацию, когда язык изменится, а аналогичная библиотека — нет. ARK>К примеру, сейчас в линке в query comprehension нет Distinct(), а в библиотеке есть. Не делай мне так смешно.
Библиотека уже изменилась, когда в ней появился Distinct.
Но я говорю вообще не об этом.
Если я захочу переписывать query comprehension не в вызовы методов, а в что-то другое то я смогу это сделать.
А в случае с библиотекой тебе придется выкинуть и переписать весь код.
ARK>Вот когда построение DSL станет _общепринятой_ практикой, тогда и можно будет делать выводы наподобие "ДСЛ скрывает реализацию неизмеримо лучше, чем библиотека". А пока что это просто слова.
Это просто факты. И никакая "общепринятость" не может их изменить.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Причем не в академическом проекте, который существует только в бурных подростковых фантазиях его авторов, а в реальной коммерческой системе, приносящей неиллюзорные деньги. WH>Что наступил на мозоль?
. Изменение этих DSLей или изменение их поведения занимает по трудоемкости не меньше, чем изменение и обновление любой другой библиотеки в проекте. WH>Ох, как ты подставляешься то... WH>Из твоей презентации. WH>
WH>● Once, as a very young company, Klarna had all the business logic in Erlang code
WH>● Management/Finance could not read it
WH>● Developers required both to change logic and to explain the current logic
WH>● Code upgrade necessary for all changes
WH>● No trace of how decisions were made
WH>Ровно то, что я говорю.
Где тут то, о чем ты говоришь? В контексте ветки ты утверждаешь, что:
1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
Да, возможно.
2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
Общая фраза, требующая доказательств. Особенно про «очень».
3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ.
Как раз в моих описаниях говорится про то, что DSL пришлось изменять.
Более того, я говорил следующее:
Если на DSL уже написаны сотни/тысячи строк кода, то любое его изменение приведет к поломке всего этого кода или изменению его поведения.
И на это мы один или два раза наткнулись, изменяя как этот DSL, так и другой. Но как ты там говоришь? А, то что твой опыт — единственно верный и правильный, а опыт других людей — ложь, ага.
Как там у тебя было,
В моей практике был случай, когда мне для дальнейшего развития библиотеки пришлось нахрен разломать весь интерфейс. Ибо в начале разработки было не ясно, что к чему.
Здравствуйте, minorlogic, Вы писали:
M>Т.е. разработчик скорее болен чем то уникальным . если интерфейс назвать магическим DSL то он может отделить реализацию , а на уровне интерфейса к библиотеке нет ? И по такому анекдотичному примеру ты строишь предположеничя ?
Начнем с того что интерфейс в терминах C# или жабы это УЖЕ детали реализации которые часто просто не нужны.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Проблемы есть. Если библиотека более-менее отражает логику бизнес-процесса или просто логику программы, то компилятор отразит что?
Не правильно. Это уже бизнес логика, написанная на библиотеке.
Библиотека отражает вычислительную модель бизнес логики.
Ровно тем же занимается компилятор. Только гораздо более прямым способом.
WH>>Это не сказки. Это УЖЕ работает. M>Где?
У меня на компе.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Каким образом SQL обеспечивает ACID, можно узнать? А то в MySQL есть движок без гарантий ACID, но в нем есть SQL.
Выключи дурака. Не смешно уже.
Сам по себе язык естественно ничего не обеспечивает. Обеспечивает его реализация. И там где она это обеспечивает про это вообще думать не надо.
Но при работе с файлом руками тебе каждый раз придется про это думать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AlexRK, Вы писали:
WH>>>У меня сейчас просто нет тех исходников. ARK>>Я не прошу исходники, я прошу демонстрационный пример. WH>Какой пример? Мне что его из пальца высосать?
Мне все равно, какой и откуда. Я прошу, чтобы вы свое утверждение — "Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ" — подтвердили примером, а не словами "в моей практике такое было".
Я прошу пример по той причине, что мне кажется, что это утверждение ложно.
ARK>>Кстати, я вполне могу представить ситуацию, когда язык изменится, а аналогичная библиотека — нет. ARK>>К примеру, сейчас в линке в query comprehension нет Distinct(), а в библиотеке есть. WH> Не делай мне так смешно. WH>Библиотека уже изменилась, когда в ней появился Distinct.
Ну вы приведите пример-то, уж сколько прошу. А я тоже посмеюсь.
WH>Но я говорю вообще не об этом. WH>Если я захочу переписывать query comprehension не в вызовы методов, а в что-то другое то я смогу это сделать. WH>А в случае с библиотекой тебе придется выкинуть и переписать весь код.
Да ну? Что же мне мешает упрятать за вызовами методов что угодно иное?
ARK>>Вот когда построение DSL станет _общепринятой_ практикой, тогда и можно будет делать выводы наподобие "ДСЛ скрывает реализацию неизмеримо лучше, чем библиотека". А пока что это просто слова. WH>Это просто факты. И никакая "общепринятость" не может их изменить.
Эти факты к вашим далеко идущим выводам отношения имеют не больше, чем наличие дядьки в Киеве.
Re[27]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
M>Да, возможно.
По твоей ссылке на порядок.
M>
M>2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
M>Общая фраза, требующая доказательств. Особенно про «очень».
А что тут доказывать то?
Берем код на старом.
Парсим.
Компилируем его в новый.
Радуемся жизни.
Не раз так делал.
M>
M>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ.
M>Как раз в моих описаниях говорится про то, что DSL пришлось изменять.
Где я написал, что ДСЛ никогда и ни при каких обстоятельствах не придется изменять?
Я утверждаю две вещи:
1)Если ДСЛ придется изменить, это потребует на порядок другой меньше работы, чем изменение интерфейса библиотеки, которая делает то же самое.
2)Многие вещи, которые требуют изменения интерфейса библиотеки, не требуют изменения ДСЛ.
Но ты споришь с чем попало кроме того что я говорю.
M>И на это мы один или два раза наткнулись, изменяя как этот DSL, так и другой. Но как ты там говоришь? А, то что твой опыт — единственно верный и правильный, а опыт других людей — ложь, ага.
И что ваш компилятор не смог выдать сообщение об ошибке?
Или предупреждение?
Это же даже в рукопашном компиляторе на раз делается.
M>В общем, с фанатиками разговаривать неинтересно.
В зеркало посмотри.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
M>>Да, возможно. WH>По твоей ссылке на порядок.
Ну да, из текста, который говорит: из 5к строчек мы получаем 50к сгенеренного кода ты делаешь далеко идущий вывод, что библиотека, существовашая до этого, имела 50 к кода. Ну-ну.
M>>
M>>2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
M>>Общая фраза, требующая доказательств. Особенно про «очень». WH>А что тут доказывать то? WH>Берем код на старом. WH>Парсим. WH>Компилируем его в новый. WH>Радуемся жизни. WH>Не раз так делал.
О да, компилятор их нового в старый с сохранением семантики — это, безусловно обязательно очень легкая задача, ага.
M>>
M>>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ.
M>>Как раз в моих описаниях говорится про то, что DSL пришлось изменять. WH>Где я написал, что ДСЛ никогда и ни при каких обстоятельствах не придется изменять? WH>Я утверждаю две вещи: WH>1)Если ДСЛ придется изменить, это потребует на порядок другой меньше работы, чем изменение интерфейса библиотеки, которая делает то же самое.
Доказательств кроме «я, у меня» ты так и не смог предоставить ни одного.
WH>2)Многие вещи, которые требуют изменения интерфейса библиотеки, не требуют изменения ДСЛ.
Это ты тоже кроме как «я, у меня» аргументировать не смог.
M>>И на это мы один или два раза наткнулись, изменяя как этот DSL, так и другой. Но как ты там говоришь? А, то что твой опыт — единственно верный и правильный, а опыт других людей — ложь, ага. WH>И что ваш компилятор не смог выдать сообщение об ошибке? WH>Или предупреждение? WH>Это же даже в рукопашном компиляторе на раз делается.
Именно потому, что компилятор выдавал сообщения об ошибке, приходилось перелопачивать все места, где использоввался этот DSL. Мегаумному Вульфхаунду, который никогда не включает дурачка, не приходит в голову, что замена синтаксиса «a PLUS b» на «a + b» в DSLе приведет к тому, что надо будет менять все места, где эта конструкция вызывается?
Здравствуйте, WolfHound, Вы писали:
I>>А с языком именно это и надо, потому что мало людей которые скажем теорию категорий на раз понимают. WH>Я уже вообще не понимаю, что ты сказать пытаешься. WH>Причем тут теория категорий?
При том, что язык поначалу может быть сколь угодно кривой. Что бы сделать рефакторинг, нужно не только поменять язык, нужно автоматически пофиксить кодовую базу, а это больше похоже на миграции.
Re[13]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
I>Мне этот дсл ровно ничего не даёт, потому я обхожусь без него Причины простые — его дизайнил непойми кто. В говнобиблиотеке проще разбираться что в таких вот говнодсл. Не ясно, откуда возьмется должное количество дсл-архитекторов, что бы на каждый проект хватило.
Наследование используют? Оно покритичнее к ошибкам будет.
I>Не знаю, как ты считал это доминирование, я через день нахожу в разных проектах самопальные парсеры Если посчитать количество этих самопальных парсеров, сильно сомневаютьс, что регэксы будут доминировать.
А они точно регулярные грамматики парсят?
Re[29]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Ну да, из текста, который говорит: из 5к строчек мы получаем 50к сгенеренного кода ты делаешь далеко идущий вывод, что библиотека, существовашая до этого, имела 50 к кода. Ну-ну.
Нет. Я делаю вывод о том, что без ДСЛ у тебя было бы не 5К строк прикладной логики, а 50К.
M>О да, компилятор их нового в старый с сохранением семантики — это, безусловно обязательно очень легкая задача, ага.
Не раз такое делал.
Это очень просто.
WH>>1)Если ДСЛ придется изменить, это потребует на порядок другой меньше работы, чем изменение интерфейса библиотеки, которая делает то же самое. M>Доказательств кроме «я, у меня» ты так и не смог предоставить ни одного.
А то, что это доказано по твоей ссылке не считается?
Ведь если бы у тебя было бы 50К строк на эрланге, то при изменении библиотеки тебе бы пришлось все их перелопатить.
А учитывая то что он динамически типизированный
WH>>2)Многие вещи, которые требуют изменения интерфейса библиотеки, не требуют изменения ДСЛ. M>Это ты тоже кроме как «я, у меня» аргументировать не смог.
Опять же читай свою ссылку.
Видишь, тут нет ни одной завязки на реализацию.
== Allowed to Purchase ==
* first of
** person.is_vip
** person.income >= limits.min_income
** all of
*** person.country = "FI"
*** [[#Finnish Special Cases]]
Теперь сравни это с тем, что из этого кода генерируется.
M>Именно потому, что компилятор выдавал сообщения об ошибке, приходилось перелопачивать все места, где использоввался этот DSL.
Ты так говоришь как будто сообщения компилятора это что-то плохое.
Хотя, что еще ждать от фаната динамической типизации.
M>Мегаумному Вульфхаунду, который никогда не включает дурачка, не приходит в голову, что замена синтаксиса «a PLUS b» на «a + b» в DSLе приведет к тому, что надо будет менять все места, где эта конструкция вызывается?
А я хотя раз сказал, что не придется?
Всё что я говорю, что то же самое придется делать и в случае с библиотеками.
Но из-за того что кода будет на порядок больше придется заниматься этим в намного больших объемах.
А некоторые изменения, которые я делал в реализации ДСЛ, с библиотекой я бы никогда не сделал. Ибо пришлось бы выкинуть весь код. А в случае с ДСЛ пришлось только перекомпилировать написанный на нем код.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, koodeer, Вы писали:
K>Пусть это не тянет на DSL, но тянет на примеры того, где макросы могут сильно помочь, вводя проверки формата на этапе компиляции.
А при чем тут макросы?
K>Глянул сейчас форум Regular Expressions на MSDN — ни одного неотвеченного вопроса.
При чем тут неотвеченные вопросы?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, koodeer, Вы писали:
K>Здравствуйте, Ziaw, Вы писали:
Z>> a.Insert(b) и insert b into a
K>Я именно такие примеры имел в виду, когда писал ранее о плохой подаче информации о макросах и дслях. Большинство обучающих примеров сделаны именно так: сперва пишется некая простая функция (Insert()), потом она заменяется на макрос (insert into). В итоге читатель не видит никакой разницы, уменьшения кода не происходит, понимание не улучшается.
Давайте я покажу пример чуть сложнее из нашего проекта. Задание бизнес-логики, объявление функционала в виде композиции других функционалов.
java:
K>Информацию следует подавать по другому: брать приличный кусок кода, который невозможно сократить с помощью стандартных средств (языки без МП), и показывать пример, как этот код может быть заменён однострочным макросом. Для затравки, привития интереса — самое то.
Re[25]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>У нас на работе используется три DSLя.
Бесполезно (я все ждал когда спор перейдет в эту плоскость). AVK вон последнее время большую часть времени занят написанием DSL, а все теоретик. Практики же, как правило, вообще ни одного промышленно применяющегося DSL не создали.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Не делай мне так смешно.
Если посчитать количество этих самопальных парсеров, сильно сомневаютьс, что регэксы будут доминировать.
