Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, dimgel, Вы писали:
D>>А можно поподробнее? (Помню ещё сто лет назад сказанное Синклером, что накосячили в угоду "естественноязыковости", но тоже без деталей).
AVK>Это я писал, а не Синклер. Что конкретно тебя интересует? Ошибки, собственно, две основных — попытка сделать язык близким к естественному английскому, что привело к тяжеловесному индексу, и крайняя бедность средств декомпозиции, из-за чего копипаста в сиквеле цветет махровым цветом.
Тяжеловесный наверное все-таки синтаксис, а не индекс? А какой был бы менее тяжеловесный?
И какие могли бы быть средства декомпозиции, например?
Вот есть линк, он сильно похож на SQL. В нем есть все те же ошибки?
Re[17]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>Ошибки, собственно, две основных — попытка сделать язык близким к естественному английскому, что привело к тяжеловесному индексу,
Вот тут интересен набросок примера, как бы оно могло выглядеть лучше.
AVK>и крайняя бедность средств декомпозиции, из-за чего копипаста в сиквеле цветет махровым цветом.
Тут понял.
Re[18]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, dimgel, Вы писали:
D>Вот тут интересен набросок примера, как бы оно могло выглядеть лучше.
Даже нормальный набросок синтаксиса это большая и непростая работа. А если отдельные моменты — ну вот начинать запрос явно логичнее не с select list (выражения после ключевого слова select), а с перечисления источников данных (то что после ключевого слова from). Синтаксис джойнов мог бы быть полаконичнее. Вычурные формы функций из стандарта никому не нужны (хотя де-факто в реальных реализациях их почти нет). И т.д.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Ikemefula, Вы писали:
I>Вот реальный пример, надо без документации сказать в чем разница между "b render a" , "a render b" и "render a b" I>Валяй, полагаю, раз это дсл, то для тебя не составит труда рассказать в чем мулька.
Давай сравним с b.render(a), a.render(b) и Render.render(a, b). Проще стало? Нету разницы, не надо демонизировать DSL.
I>Синтаксис это ерунда. В библиотеку очень легко заглянуть, а дсл это черный ящик и собственно черный ящик большей частью непригоден в софтостроении.
Снова уперлись в недостатки тулзов. Ок, принято.
Re[15]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>Форматная строка на DSL, извини, не тянет.
Еще как тянет, ее обрабатывает парсер совмещенный с интерпретатором простеньких команд. Чем не язык?
AVK>Что же касается остального — SQL обычно специально указывают в требованиях вакансии, что как бы намекает (при этом по настоящему хорошо его знает 1% от считающих так). А регексы это вообще что то с чем то — одно только количество вопросов форуме типа "подскажите регекс для ..." уже о многом говорит. Лично мне до сих пор иногда приходится вдумчиво вчитываться в доку по регекпам, и я уверен, что библиотека без этой птичей псевдографики была бы проще и удобнее.
Ты озвучь наконец свою позицию, полезны только широко известные DSL (тогда я отстану от SQL, а ты перестанешь указывать что его все знают) или все DSL вредны (тогда давай реальные альтернативы форматным строкам и регэкспам, без "я уверен, что библиотека без этой птичей псевдографики была бы проще и удобнее").
AVK>Можешь в янусе посмотреть — там все запросы к БД без использования QC написаны. Более того, SQL, который там был раньше — мутнее и сложнее. Особенно весело с запросом, обновляющим агрегаты — трехстраничное сиквельное чудовище превратилось в 60 хорошо читаемых строк.
. Посылать меня в янус не надо, ты его код знаешь, сам и давай ссылки на сложные запросы.
AVK>А все потому что проектировщики SQL допустили ряд грубых ошибок в его дизайне. И это, заметь, люди, которые неплохо представляли то, чем они занимаются. Что же получится из под пера кучи ньюбов, пусть и вооруженных прекрасным инструментом для создания парсеров и анализаторов — я представляю себе с содроганием.
Допустили. C# это исправил другим DSLем. Недостатки SQL видны хорошо, ктож спорит. Идеальных решений не бывает. Альтерантивы только грустные, без DSL все равно все плохо.
AVK>Масштаб проблем несколько разный. Библиотеку я в полуавтоматическом режиме почистить могу, где то вставляя временные подпорки (не заморачиваясь никакими языкостроительными тулами). А что делать, когда кастомный DSL надо сильно переделать или вообще выкинуть?
А что делать, если надо заменить или выкинуть ORM? DI? Переколбасить пол проекта, делов-то. По этой причине люди не отказались ни от того ни от другого.
Re[18]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
M>Только вот у некоторых пропонентов DSLей зашорены глаза: мол, DSLи и понятны сразу, и документированы сразу, и инструментарий есть и вообще, это панацея от всего (можно почитать предыдущие топики на эти же темы). Что, естественно, далеко не так.
Конечно не так.
а) По понятности не уступают обычному коду.
б) Документированы обычно не хуже альтернативного инструмента без DSL.
в) Основной объективный недостаток на сегодняшний день — трудность создания и худшая поддержка IDE.
г) Панацеей не являются, но без DSL жизни нет во многих областях.
А твой прием демагогии называется "довести высказывания собеседника до абсурда".
Re[19]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
M>>Только вот у некоторых пропонентов DSLей зашорены глаза: мол, DSLи и понятны сразу, и документированы сразу, и инструментарий есть и вообще, это панацея от всего (можно почитать предыдущие топики на эти же темы). Что, естественно, далеко не так.
Z>Конечно не так.
Z>а) По понятности не уступают обычному коду. Z>б) Документированы обычно не хуже альтернативного инструмента без DSL. Z>в) Основной объективный недостаток на сегодняшний день — трудность создания и худшая поддержка IDE. Z>г) Панацеей не являются, но без DSL жизни нет во многих областях.
Ого. Внезапно. Дай-ка я тебе процитирую мое высказывание, с которым ты внезапно не согласился, начав весь этот спор
У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.
И внезапно ты, по сути, повторяешь мои слова
Z>А твой прием демагогии называется "довести высказывания собеседника до абсурда".
Я просто брал твои высказывания без изменений. До абсурда ты их доводил сам.
Здравствуйте, AndrewVK, Вы писали:
WH>>Там от SQL только синтаксис одинаковый. AVK>Этого мало? Ну и не только синтаксис — семантика всех конструкций тоже идентична.
Это такая мелочь, что не стоит внимания. Но и даже с синтаксисом не всё хорошо. Он местами различается.
А вот с семантикой там всё очень по-разному. И зависит от реализации самой БД. А когда дело доходит до TSQL, PLSQL итп то там вообще всё разное.
К остальному как я понял, претензий нет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
I>>Вот реальный пример, надо без документации сказать в чем разница между "b render a" , "a render b" и "render a b" I>>Валяй, полагаю, раз это дсл, то для тебя не составит труда рассказать в чем мулька.
Z>Давай сравним с b.render(a), a.render(b) и Render.render(a, b). Проще стало? Нету разницы, не надо демонизировать DSL.
Ты чего сказать хотел, что отличия только в синтаксисе ? Если так, то ДСЛ не нужен.
I>>Синтаксис это ерунда. В библиотеку очень легко заглянуть, а дсл это черный ящик и собственно черный ящик большей частью непригоден в софтостроении.
Z>Снова уперлись в недостатки тулзов. Ок, принято.
В случае с SQL или регексов этот недостаток так и не был преодолен
Re[19]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ikemefula, Вы писали:
WH>>Подсветка, навигация, автокомплит и переименование получаются вообще автоматом. WH>>А это 80% потребностей. С форматированием сложнее. Но и там не так уж и много придется написать. WH>>А более сложные вещи для 99% ДСЛ и не понадобятся никогда.
Что характерно твоё сообщение не имеет ничего общего с тем, на что ты отвечаешь.
I>Для дсл нужен непосредственный доступ к модели, для изучения, исследования, оптимизации и тд,
Вот тут ДСЛ впереди планеты всей. Это я тебе говорю как человек, который только ими и занимается.
I>иначе будет как с SQL, большинство использует "по рецептам", малая часть думает что знает, и только ничтожная действительно знает SQL. I>С регэксами тож самое, перестал пользоваться на время — все забыто и надо снова документацию перечитывать.
Я бы посмотрел на то как ты руками будешь выписывать работу с файлом с ACID в полный рост. Или хотя бы ДКА для разбора текста.
I>Т.е. нужен не дсл, а четкая прозрачная модель с хорошим апи.
Ага, конечно. Каким АПИ ты собрался SQL заменить?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, dimgel, Вы писали:
D>В основном я долблю в нежелание помнить новый синтаксис вместе с новой семантикой. Но ты ниже по этому поводу мне мозги прочистил
. Но в данном случае я ещё имею в виду ненависть по отношению ко всякой boilerplate-магии (e.g. аспекты, а в данном случае и макросы), в которую приходится вникать, чтобы понять, как оно работает. Зачастую эта магия на порядки сложнее не только, чем тот код, который её использует, но и чем аналогичный по функционалу код, который обошёлся без неё. А изучать её при отладке частенько приходится приходится.
Да, с синтаксисом есть такая беда. Надо лезть в доку, нельзя восстановить знания тыкаясь в комплишен. Вот это одна из основных проблем DSL, вторая — сложность его проектирования и рефакторинга. Инструментальные проблемы сейчас решают довольно много людей в мире, я думаю через несколько лет инструменты будут довольно приятные. Сложность проектирования DSL возникла от неправильной постановки задачи: "а давай забабахаем тут DSL". А должна она ставиться так — "вот эту конструкцию, проще и нагляднее будет записывать так, давай подумаем, сможем ли мы записать аналогичные конструкции так же красиво". Простенькие встроенные DSL хороши тем, что от них, зачастую, можно отказаться в пользу нижележащего API, просто рассахарить вручную, если DSL вдруг слажал и не дает сделать что-то нужное.
D>Гыгы, уел. Но я имел в виду, опять же, boilerplate-магию. В тех же макросах можно прикрутить другую семантику к синтаксису вызова метода (и вроде бы даже в каких-то простеньких макросах так и делали — а это уже тот самый #define true false), а без макросов вызов метода — это вызов метода и ничего более.
Макросы тут не являются чем-то особенным. Мне вот сейчас надо добавить функционал в мой старый проект, которому лет 10. Там аспекты безо всяких макросов, средствами spring и dynamic proxy. То, что выглядит как обычный вызов метода, с навешанными аспектами превращается в проверку прав и управление транзакциями. Это позволило сократить кучу кода и соответственно ошибок. Сначала меня охватила тоска, когда я понял, что придется кропотливо разбираться, как оно все работает. Но, когда разобрался, стало понятно, что это было оправдано, никакой альтернативы аспектам у меня не нашлось и сейчас.
К чему это я? Все эти магии они не от хорошей жизни возникают, а продиктованы отсутствием вменяемых альтернатив.
Re[20]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
AVK>>Этого мало? Ну и не только синтаксис — семантика всех конструкций тоже идентична. WH>Это такая мелочь, что не стоит внимания.
Конечно. Именно поэтому SQL и популярен.
WH> Но и даже с синтаксисом не всё хорошо. Он местами различается.
У большой тройки, если не брать экзотики, SQL'99 поддержан на 100%. У второго эшелона ситуация почти такая же, даже FB с его чудесами подтянулся. Так что расширения синтаксиса есть, изменений относительно базового нет.
WH>А вот с семантикой там всё очень по-разному. И зависит от реализации самой БД.
Например?
WH> А когда дело доходит до TSQL, PLSQL итп то там вообще всё разное.
Ну так потому императивные расширения и нужны только маньякам.
WH>К остальному как я понял, претензий нет.
К чему остальному?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Ziaw, Вы писали:
AVK>>Форматная строка на DSL, извини, не тянет. Z>Еще как тянет
Нет, не тянет. Иначе мы может DSL обозвать чуть менее чем все, что какое то подобие парсера имеет, например CSV. А по факту обзывать форматированный вывод доменом можно только от очень большого энтузиазма.
Z>Ты озвучь наконец свою позицию, полезны только широко известные DSL (тогда я отстану от SQL, а ты перестанешь указывать что его все знают) или все DSL вредны (тогда давай реальные альтернативы форматным строкам и регэкспам, без "я уверен, что библиотека без этой птичей псевдографики была бы проще и удобнее").
У меня нет простого ответа на этот вопрос. В каждой конкретной ситуации надо смотреть отдельно. Я могу утверждать лишь две вещи:
1) Изобретать DSL всегда и везде — безумная крайность
2) Решение о создании DSL должно приниматься только при наличии огромных бенефитов, размером в человекогоды экономии на разработке минимум.
3) Решение в принципе никогда не создавать DSL в любой ситуации — такая же безумная крайность.
Z>Допустили. C# это исправил другим DSLем. Недостатки SQL видны хорошо, ктож спорит.
Вопрос в цене. Недостатки в библиотеках исправляются в последующих релизах, недостатки сиквела, видимо, по большей части уже не исправят никогда.
Z>А что делать, если надо заменить или выкинуть ORM?
Я такое в том же янусе делал, два раза. Все срастается в разумные сроки в том числе благодаря решарперу.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Вопрос в цене. Недостатки в библиотеках исправляются в последующих релизах, недостатки сиквела, видимо, по большей части уже не исправят никогда.
Это просто лож.
ДСЛ исправлять проще, чем библиотеку.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, AndrewVK, Вы писали:
AVK>>Вопрос в цене. Недостатки в библиотеках исправляются в последующих релизах, недостатки сиквела, видимо, по большей части уже не исправят никогда. WH>Это просто лож. WH>ДСЛ исправлять проще, чем библиотеку.
Угу. Особенно если на этом DSL уже наколбашены сотни кода.
Re[18]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
AVK>>Вопрос в цене. Недостатки в библиотеках исправляются в последующих релизах, недостатки сиквела, видимо, по большей части уже не исправят никогда. WH>Это просто лож. WH>ДСЛ исправлять проще, чем библиотеку.
Здравствуйте, WolfHound, Вы писали:
I>>Для дсл нужен непосредственный доступ к модели, для изучения, исследования, оптимизации и тд, WH>Вот тут ДСЛ впереди планеты всей. Это я тебе говорю как человек, который только ими и занимается.
Пока что во всех твоих примерах ты прячешь модель куда подальше.
I>>иначе будет как с SQL, большинство использует "по рецептам", малая часть думает что знает, и только ничтожная действительно знает SQL. I>>С регэксами тож самое, перестал пользоваться на время — все забыто и надо снова документацию перечитывать. WH>Я бы посмотрел на то как ты руками будешь выписывать работу с файлом с ACID в полный рост. Или хотя бы ДКА для разбора текста.
А я где то утверждал что все это надо руками выписывать ?
I>>Т.е. нужен не дсл, а четкая прозрачная модель с хорошим апи. WH>Ага, конечно. Каким АПИ ты собрался SQL заменить?
Например таким как в linq, если ты не забыл, linq это не query comprehension.
А какой был бы менее тяжеловесный?
Но я имел в виду, опять же, boilerplate-магию. В тех же макросах можно прикрутить другую семантику к синтаксису вызова метода (и вроде бы даже в каких-то простеньких макросах так и делали — а это уже тот самый #define true false), а без макросов вызов метода — это вызов метода и ничего более.