Здравствуйте, Mamut, Вы писали:
M>Ого. Внезапно. Дай-ка я тебе процитирую мое высказывание, с которым ты внезапно не согласился, начав весь этот спор M>
M>У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.
Ну так я и возразил, что документирован не хуже альтернативных библиотек. Ты зачастую используешь недокументированные библиотеки?
Re[17]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>У меня нет простого ответа на этот вопрос. В каждой конкретной ситуации надо смотреть отдельно. Я могу утверждать лишь две вещи: AVK>1) Изобретать DSL всегда и везде — безумная крайность
Согласен.
AVK>2) Решение о создании DSL должно приниматься только при наличии огромных бенефитов, размером в человекогоды экономии на разработке минимум.
Не согласен. В общем случае достаточно разницы по сложности в 3-4 раза, между решением с DSL и решением без него.
А в частных случаях микроDSL можно даже без особого профита в трудоемкости. Просто для чистоты кода. Типа макроса lazy в nemerle.
AVK>3) Решение в принципе никогда не создавать DSL в любой ситуации — такая же безумная крайность.
Согласен.
AVK>Вопрос в цене. Недостатки в библиотеках исправляются в последующих релизах, недостатки сиквела, видимо, по большей части уже не исправят никогда.
Да, вопрос в цене альтернатив. При всех недостатках он сослужил свою службу очень достойно, да и еще послужит немало. SQL как математика, хорош хотя бы тем, что мысли в порядок приводит.
AVK>Я такое в том же янусе делал, два раза. Все срастается в разумные сроки в том числе благодаря решарперу.
[trol mode on]
Вооо! не было бы ОРМ, не пришлось бы целых два раза все менять!
[trol mode off]
Зачастую проблемы взять все и переделать сильно преувеличенны и все срастается в разумные сроки. Описанный тобой риск конечно есть и его надо учитывать, как и все другие, но ведь их надо не тупо бояться, а соизмерять с альтернативой.
Re[21]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
WH>>Ага, конечно. Каким АПИ ты собрался SQL заменить?
I>Например таким как в linq, если ты не забыл, linq это не query comprehension.
M>>Ого. Внезапно. Дай-ка я тебе процитирую мое высказывание, с которым ты внезапно не согласился, начав весь этот спор M>>
M>>У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.
Z>Ну так я и возразил, что документирован не хуже альтернативных библиотек. Ты зачастую используешь недокументированные библиотеки?
Я уже давно понял, что для тебя DSL — это только и исключительно документированные сторонние библиотеки. Остальное ты DSLями не считаешь. Про это я уже тоже где-то говорил, вроде. DSL не обязательно является сторонней документированной библиотекой. Это может быть внутренний DSL, созданный для проекта. Я даже пример приводил.
Ну и даже если это сторонняя библиотека. Вот у нас используется веб-сервер Yaws, который существует года этак с 2003-го. Вполне себе сторонняя библиотека. По идее должна быть уже задокументирована по самое нехочу. Ага, тот самый случай. Как начинаешь ковыряться чуть ниже уровня «а вот мы здесь создаем страницу», начинается трэш и угар. Аналогично для очень большого количества библиотек.
Что было бы, если бы это был DSL при таком же уровне документации? Расковыривать EBNF/Peg/Yacc/хз-что? Реверс-инжинирить работу компилятора/интерпретатора этого DSL? И если в Yaws при желании можно пройтись по кишкам дебаггером, то что ты предлагаешь для DSL? Сказки Вульфхаунда, что это все не проблема?
Здравствуйте, Ikemefula, Вы писали:
Z>>Давай сравним с b.render(a), a.render(b) и Render.render(a, b). Проще стало? Нету разницы, не надо демонизировать DSL.
I>Ты чего сказать хотел, что отличия только в синтаксисе ? Если так, то ДСЛ не нужен.
Это твой DSL вообще-то, тебе виднее в чем там отличия. Я хотел сказать, что знание синтаксиса не дает тебе ничего, кроме понимания, что тут вызывается какой-то метод.
Z>>Снова уперлись в недостатки тулзов. Ок, принято.
I>В случае с SQL или регексов этот недостаток так и не был преодолен
И это не мешает им доминировать на рынке. При всех их недостатках, практически все альтернативы ужасно печальны.
Re[19]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
WH>>ДСЛ исправлять проще, чем библиотеку. ARK>Угу. Особенно если на этом DSL уже наколбашены сотни кода.
Именно.
1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ.
Например, я полностью изменил реализацию парсера при этом синтаксис и семантика не изменились.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
WH>>>Ага, конечно. Каким АПИ ты собрался SQL заменить?
I>>Например таким как в linq, если ты не забыл, linq это не query comprehension.
Z>Замени это
Ты хочешь мне доказать, что в linq самое сложное это query comprehension , а все остальное это типовые задачи для студентов первого курса ?
Я прямо и не знаю, что и думать. Скажу, для пробы, да, ты прав, в linq самое сложное это query comprehension
Re[19]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Вот есть DSL под названием SQL. Покажи мне, как можно его исправить проще, заменив нестандартный синтаксис на стандартный.
Тебе никак. А вот автору БД без проблем. Мы же тут говорим про создание своих ДСЛ. А значит, мы можем их исправлять.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
WH>>>ДСЛ исправлять проще, чем библиотеку. ARK>>Угу. Особенно если на этом DSL уже наколбашены сотни кода. WH>Именно. WH>1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
И DSL и библиотека являются интерфейсом к какому-то большому коду. Если на DSL уже написаны сотни/тысячи строк кода, то любое его изменение приведет к поломке всего этого кода или изменению его поведения. Точно так же, если библиотека используется в сотнях/тысячах мест, то эти места сломаются/поменяют поведение, если мы изменим библиотеку.
WH>2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
Откуда внезапно взялось это правило?
WH>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ. WH>Например, я полностью изменил реализацию парсера при этом синтаксис и семантика не изменились.
КО напоминает, что если библиотека реализована, как черный ящик, то меняй эту реализацию хоть сто раз. Неубедительно.
Здравствуйте, Ikemefula, Вы писали:
I>Пока что во всех твоих примерах ты прячешь модель куда подальше.
В смысле?
WH>>Я бы посмотрел на то как ты руками будешь выписывать работу с файлом с ACID в полный рост. Или хотя бы ДКА для разбора текста. I>А я где то утверждал что все это надо руками выписывать ?
А к чему тогда ты это всё понаписал?
I>Например таким как в linq, если ты не забыл, linq это не query comprehension.
Те другим ДСЛ. Ибо fluent interface это тоже ДСЛ. Обычно очень кривой и тормозной.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Вот есть DSL под названием SQL. Покажи мне, как можно его исправить проще, заменив нестандартный синтаксис на стандартный. WH>Тебе никак. А вот автору БД без проблем. Мы же тут говорим про создание своих ДСЛ. А значит, мы можем их исправлять.
Как ты там рядом говорил? Легкая трансформация? Вот мы трансформировали наш SQL на использование window functions вместо linit x,y. ВНЕЗАПНО оказалось, что все у всех перестало работать. А как же сказки о безболезненном изменении DSL
Здравствуйте, Mamut, Вы писали:
Z>>Ну так я и возразил, что документирован не хуже альтернативных библиотек. Ты зачастую используешь недокументированные библиотеки?
M>Я уже давно понял, что для тебя DSL — это только и исключительно документированные сторонние библиотеки. Остальное ты DSLями не считаешь. Про это я уже тоже где-то говорил, вроде. DSL не обязательно является сторонней документированной библиотекой. Это может быть внутренний DSL, созданный для проекта. Я даже пример приводил.
Может быть и зачастую это разные вещи, ты не находишь? Обычно используются документированные сторонние DSL, внутренние для проекта сильно реже. Еще реже их не документируют. Еще раз, я протестую против слова "зачастую".
M>Ну и даже если это сторонняя библиотека. Вот у нас используется веб-сервер Yaws, который существует года этак с 2003-го. Вполне себе сторонняя библиотека. По идее должна быть уже задокументирована по самое нехочу. Ага, тот самый случай. Как начинаешь ковыряться чуть ниже уровня «а вот мы здесь создаем страницу», начинается трэш и угар. Аналогично для очень большого количества библиотек.
Ты еще конфиг для sendmail вспомни. Вот уж где эпичный фейл DSLстроения, но немногие хорошо освоившие юзают и считают, что без него было бы хуже. Даже ужасный DSL иногда кому-то может быть полезен. Но, главное, примеры ужасных библиотек, как и DSL не доказывают ровным счетом ничего, кроме возможности их существования. А сей факт мне доказывать не надо.
M>Что было бы, если бы это был DSL при таком же уровне документации? Расковыривать EBNF/Peg/Yacc/хз-что? Реверс-инжинирить работу компилятора/интерпретатора этого DSL? И если в Yaws при желании можно пройтись по кишкам дебаггером, то что ты предлагаешь для DSL? Сказки Вульфхаунда, что это все не проблема?
Предлагаю ругать не DSL а доступные тебе инструменты для его создания. Проблема в них.
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Какой то не очень удачный у тебя пример для демонстрации преимуществ QC. На BLT в виде method chain переписывается даже короче и получается что то вроде:
orderDetails =
db
.OrderDetails(od => od.Order.OrderID = orderID)
.Select(
od =>
new OrderDescription
{
Product = od.Product.ProductName,
Quantity = od.Quantity,
ShipperName = od.Order.ShipVia.CompanyName,
Total = od.Quantity * od.UnitPrice,
UnitPrice = od.UnitPrice,
SupplierName = od.Product.Supplier.CompanyName
});
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Mamut, Вы писали:
M>Что было бы, если бы это был DSL при таком же уровне документации?
Нормально все было бы.
M>Расковыривать EBNF/Peg/Yacc/хз-что?
А в чем проблема?
Это не сложнее чем читать код на ерланге.
M>Реверс-инжинирить работу компилятора/интерпретатора этого DSL?
А что просто в исходники заглянуть не судьба?
M>И если в Yaws при желании можно пройтись по кишкам дебаггером, то что ты предлагаешь для DSL?
Пройтись по кишкам отладчиком.
Можно ходить и по самому компилятору.
И по ДСЛ. И по сгенерированному коду. Н2 находится в зачаточном состоянии но уже можно ходить отладчиком как по сходному коду на ДСЛ. Так и по сгенерированному. В будущем можно будет во время отладки переключатся.
M>Сказки Вульфхаунда, что это все не проблема?
Не сказки а ежедневный опыт работы с ДСЛ на порядки более сложным чем те которые будут создавать 99% разработчиков.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AlexRK, Вы писали:
WH>>>ДСЛ исправлять проще, чем библиотеку. ARK>>Угу. Особенно если на этом DSL уже наколбашены сотни кода. WH>Именно. WH>1)Просто по тому, что для решения той же задачи на библиотеке будут написаны тысячи, а то и миллионы кода.
Ну, это другой уже вопрос.
WH>2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит.
Вот в это я поверить не могу. Каким это магическим образом можно легко изменить весь код? Рефакторинг и в обычном коде иногда сложен, а с DSL...
А если этот DSL-код еще где-нибудь в строковых литералах лежит, как SQL?
WH>3)Многие вещи, которые требуют изменения интерфейса библиотеки можно делать без изменения ДСЛ.
И наоборот.
WH>Например, я полностью изменил реализацию парсера при этом синтаксис и семантика не изменились.
Ну, частный случай.
Re[12]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
I>>Ты чего сказать хотел, что отличия только в синтаксисе ? Если так, то ДСЛ не нужен.
Z>Это твой DSL вообще-то, тебе виднее в чем там отличия. Я хотел сказать, что знание синтаксиса не дает тебе ничего, кроме понимания, что тут вызывается какой-то метод.
Мне этот дсл ровно ничего не даёт, потому я обхожусь без него Причины простые — его дизайнил непойми кто. В говнобиблиотеке проще разбираться что в таких вот говнодсл. Не ясно, откуда возьмется должное количество дсл-архитекторов, что бы на каждый проект хватило.
I>>В случае с SQL или регексов этот недостаток так и не был преодолен Z>И это не мешает им доминировать на рынке. При всех их недостатках, практически все альтернативы ужасно печальны.
Не знаю, как ты считал это доминирование, я через день нахожу в разных проектах самопальные парсеры Если посчитать количество этих самопальных парсеров, сильно сомневаютьс, что регэксы будут доминировать.
Re[23]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>Какой то не очень удачный у тебя пример для демонстрации преимуществ QC. На BLT в виде method chain переписывается даже короче и получается что то вроде: AVK>
Отлично Да, пример оказался неудачный, одни inner join. Как только добавятся left и right станет сразу менее уютно, по навигационным свойствам гулять станет непросто. Впрочем к синтаксису QC это тоже относится.
Re[22]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Ikemefula, Вы писали:
I>>Пока что во всех твоих примерах ты прячешь модель куда подальше. WH>В смысле?
Да все просто, в linq том же мне незачем приседать, что бы выяснить, что же там происходит. В принципе, с макросами почти так же, только дольше. А вот с дсл где взять внутренности вычислительной модели ?
WH>>>Я бы посмотрел на то как ты руками будешь выписывать работу с файлом с ACID в полный рост. Или хотя бы ДКА для разбора текста. I>>А я где то утверждал что все это надо руками выписывать ? WH>А к чему тогда ты это всё понаписал?
Да как бы понятно — чего требуется от ДСЛ. Относительно автокомплитов и интелисенсов ты немного погорячился. Нужен не просто рефакторинг, нужна возможность заглянуть внутрь модели, возможность изменить не название кейворда, а его семантику. Это уже получаются миграции, а не рефакторинг. На примере SQL или регэксов хорошо видно.
I>>Например таким как в linq, если ты не забыл, linq это не query comprehension. WH>Те другим ДСЛ. Ибо fluent interface это тоже ДСЛ. Обычно очень кривой и тормозной.
На счет кривизны и тормознутости сумлеваюсь. И рукописная модель тоже дсл. Светлое бущущее про которые ты говоришь уже давно настало, опаньки !
Кстати, ты рослин уже обогнал по перформансу или нет ?
Re[21]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>И DSL и библиотека являются интерфейсом к какому-то большому коду.
С ДСЛ это не совсем верно. Обычно компилятор получается сложнее чем рантайм.
M>Если на DSL уже написаны сотни/тысячи строк кода, то любое его изменение приведет к поломке всего этого кода или изменению его поведения. Точно так же, если библиотека используется в сотнях/тысячах мест, то эти места сломаются/поменяют поведение, если мы изменим библиотеку.
1)Ты отвечаешь на то, что кода на библиотеке будет намного больше.
2)Я именно это и говорю. Но мне тут пытаются втирать, что с библиотекой проблем не будет.
WH>>2)Как правило, старый ДСЛ очень легко можно трансформировать в новый. С библиотеками такое не всегда проходит. M>Откуда внезапно взялось это правило?
Из практики.
M>КО напоминает, что если библиотека реализована, как черный ящик, то меняй эту реализацию хоть сто раз. Неубедительно.
Плохой у тебя КО.
В моей практике был случай, когда мне для дальнейшего развития библиотеки пришлось нахрен разломать весь интерфейс. Ибо в начале разработки было не ясно, что к чему.
При этом ДСЛ, которым пользовались люди, не изменился.
Всё по тому, что через интерфейс библиотеки всегда просачивается реализация. А через ДСЛ нет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Как ты там рядом говорил? Легкая трансформация? Вот мы трансформировали наш SQL на использование window functions вместо linit x,y. ВНЕЗАПНО оказалось, что все у всех перестало работать. А как же сказки о безболезненном изменении DSL
?
Ты можешь взять другой ДСЛ который это всё прячет. Например linq.
Или сделать транслятор стандартного SQL в конкретный диалект.
Но научить БД не изменяя саму БД ессно нельзя.
Я же всегда говорил в контексте того что мы можем править компилятор.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Да, пример оказался неудачный, одни inner join. Как только добавятся left и right станет сразу менее уютно, по навигационным свойствам гулять станет непросто. Впрочем к синтаксису QC это тоже относится.
