Z>В общем случае не попадаем, мы ведь не знаем точно тип a. Я правильно понимаю, что основная претензия к DSL свелась к отсутствию поддержки Ctrl-Click?
Нет
Z>Сейчас вы с Мамутом успешно сводите проблему DSL к проблемам навигации.
Нет, не сводим
D>>1. Может быть, там какой-нибудь бред в духе #define true false в реализации, переворачивающий весь этот "естественный язык" с ног на голову.
Z>Если начинать говорить про бред могу рассказать, как сделать, чтобы метод Insert начал очищать список. Но ты ведь и сам это прекрасно знаешь, зачем приводить такие аргументы?
Это — именно аргументы. В отличие от явной лжи и сказок в виде безаппеляционных заявлений «DSL обычно документирован».
D>>2. Я же не могу, прочитав эту естественную и возрадовавшись, начать писать вообще весь код в свободном стиле: "store sum of a and b to c". Z>Конечно не можешь. Точно так же не можешь начать писать a.MakeTheUniverseWorkForMe(), узнав синтаксис вызова метода и не затрудняя себя изучением контракта a.
Стоп. Это ты тут заявляешь, что DSL понятен сразу, что он якобы сразу документирован, а не мы.
Здравствуйте, Mamut, Вы писали:
M>Я просто говорю, что фраза «DSL обычно документированы» — это ложь. DSL «обычно документированы» не лучше и не хуже любого другого кода.
Я говорю то же самое. фраза «DSL зачастую недокументированы» — это ложь. DSL «обычно документированы» не лучше и не хуже любого другого кода.
Закроем тему
Re[11]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Mamut, Вы писали:
Z>>Сейчас вы с Мамутом успешно сводите проблему DSL к проблемам навигации.
M>Нет, не сводим
А к чему? Пока это единственный, действительно объективный аргумент, который можно обсуждать серьезно. Мы не можем легко увидеть конечный код, который стоит за DSL.
D>>>1. Может быть, там какой-нибудь бред в духе #define true false в реализации, переворачивающий весь этот "естественный язык" с ног на голову.
Z>>Если начинать говорить про бред могу рассказать, как сделать, чтобы метод Insert начал очищать список. Но ты ведь и сам это прекрасно знаешь, зачем приводить такие аргументы?
M>Это — именно аргументы.
Так ведь слабенькие. Опровергаются элементарно.
M>В отличие от явной лжи и сказок в виде безаппеляционных заявлений «DSL обычно документирован».
Безапелляционность была ответной. Я тебе несколько раз доступно разжевал, что я хотел этим сказать. Причем это ровно то же самое, что утверждаешь здесь ты. То, что тебе не надоело докапываться до этой фразы, означает, что больше тебе по теме сказать нечего. Все последующие попытки обыграть эту фразу в выгодном тебе свете будут идти в игнор, как махровая демагогия.
M>Стоп. Это ты тут заявляешь, что DSL понятен сразу, что он якобы сразу документирован, а не мы.
Это ложь.
Re[15]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AlexRK, Вы писали:
ARK>"Если у вас есть проблема, и вы собираетесь решать ее с использованием регулярных выражений, то теперь у вас две проблемы" (с)
ARK>Кстати, шутка-то с долей шутки. Иные regexp-ы лучше бы расписать десятком методов — хоть понятно будет (всем будет понятно, а не одному гуру в толстых очках с черепаховой оправой).
В том то и дело, что несмотря на всю проблемность регэкспов безDSLной альтернативы нет.
ARK>SQL хороший DSL. Только он разрабатывался не за неделю на коленке местным архитектором, а умными людьми. Он общепризнан, по нему полно документации. И то часто возникают проблемы. Но с SQL решение проблемы найти элементарно, а вот с самописным языком...
Он был приведен только как яркий пример, того, что DSL решения рвут бездсльные как тузик грелку. Я хотел сказать, что умные люди реализовали SQL в своих СУБД, остальные не выжили. Менее дальновидные совершенствовали мощность и простоту API, считая это лучшим сценарием.
ARK>Со своей библиотекой (и уволившимся создателем) проще все-таки. Синтаксис всем известен, работают тулы, рефакторинги и прочая.
Я выделил основную проблему. Потому и проще, что нет пока адекватных инструментов для создания DSL. Но это проблема не DSL, а неразвитости инструментов.
ARK>А вот с DSL асимптотика проблемы может и такая же, но еще есть большая скрытая константа, усугубляющая дело. ИМХО. ARK>Есть груда непонятного кода и компилятор, обрабатывающий этот код по своим правилам (с высокой долей вероятности содержащий ошибки и непредвиденные побочные эффекты).
ARK>Лично мое мнение — я бы убрал из проекта все эти мелкие DSL. Глаз сразу выцепляет чужеродный код и внутри сразу возникает напряжение: ЧТО ЭТО? Зачем это нужно, излишнее усложнение на ровном месте?
Это дело привычки. Аналогично чтению var в C#. Подавляющее большинство на него плюется, до тех пор, пока не начнет использовать. Причем аргументы примерно те же идут.
Re[16]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Это дело привычки. Аналогично чтению var в C#. Подавляющее большинство на него плюется, до тех пор, пока не начнет использовать. Причем аргументы примерно те же идут.
Есть нюансик — var один на всех. Спроектирован, задокументирован, отлажен и стандартизирован. Чего не скажешь о наколенных решениях.
В общем, время покажет, кто где прав. [vanga]Предсказываю, что самописные DSL в ближайшие годы распространения не получат.[/vanga]
Re[17]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Z>>Это дело привычки. Аналогично чтению var в C#. Подавляющее большинство на него плюется, до тех пор, пока не начнет использовать. Причем аргументы примерно те же идут.
ARK>Есть нюансик — var один на всех. Спроектирован, задокументирован, отлажен и стандартизирован. Чего не скажешь о наколенных решениях.
ARK>В общем, время покажет, кто где прав. [vanga]Предсказываю, что самописные DSL в ближайшие годы распространения не получат.[/vanga]
Только вот у некоторых пропонентов DSLей зашорены глаза: мол, DSLи и понятны сразу, и документированы сразу, и инструментарий есть и вообще, это панацея от всего (можно почитать предыдущие топики на эти же темы). Что, естественно, далеко не так.
M>>Это — именно аргументы. Z>Так ведь слабенькие. Опровергаются элементарно.
Ни одного ты не смог опровергнуть.
M>>В отличие от явной лжи и сказок в виде безаппеляционных заявлений «DSL обычно документирован».
Z>Безапелляционность была ответной. Я тебе несколько раз доступно разжевал, что я хотел этим сказать.
Да-да-да, я помню. «Если это недокументированный DSL, я его DSL-ем не считаю», «если его сделал кто-то, кто мне не нравится, я это DSL-ем не считаю» Извини, с такой аргументацией — в сад.
Z> Причем это ровно то же самое, что утверждаешь здесь ты. То, что тебе не надоело докапываться до этой фразы, означает, что больше тебе по теме сказать нечего. Все последующие попытки обыграть эту фразу в выгодном тебе свете будут идти в игнор, как махровая демагогия.
M>>Стоп. Это ты тут заявляешь, что DSL понятен сразу, что он якобы сразу документирован, а не мы.
Z>Это ложь.
Ой да ну.
DSL обычно документирован
Когда ты читаешь код a.Insert(b) и insert b into a у тебя примерно одинаково информации, для понимания того, что происходит. Но в первом случае тебе надо знать соглашения, чтобы понять, что происходит, а во втором не нужно.
Это все — твои слова. При этом когда тебе указывают на ложность этих утверждений, ты начинаешь обвинять нас, что, мол, якобы, мы утыерждаем о сверхсложности документирования DSLей, о том, что DSLи не нужны и т.п., хотя мы этого не говорим.
Повторю еще раз, о чем я говорю:
У меня главная причина неприятия — то, что любой DSL — это еще один язык, зачастую недокументированный, часто со странной и отличающейся от других языков семантикой, с отсутствием внятного инструментария и т.п.
Что в этой фразе тебе непонятно и с чем ты несогласен?
По-моему, в этом списке одни языки разметки. Может, конечно, это тоже DSL, но я имел в виду, во-первых, языки программирования, а во-вторых, самописно-наколенные, которые якобы (насколько я понял сторонников DSL-подхода) каждый завалящий архитектор пачками писать будет.
Re[14]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Regexp, SQL, format strings — это примеры DSL которыми мы все пользуемся постоянно.
Форматная строка на DSL, извини, не тянет. Что же касается остального — SQL обычно специально указывают в требованиях вакансии, что как бы намекает (при этом по настоящему хорошо его знает 1% от считающих так). А регексы это вообще что то с чем то — одно только количество вопросов форуме типа "подскажите регекс для ..." уже о многом говорит. Лично мне до сих пор иногда приходится вдумчиво вчитываться в доку по регекпам, и я уверен, что библиотека без этой птичей псевдографики была бы проще и удобнее.
Z>Причем для SQL и регэкспов она вообще за гранью реальности.
Можешь в янусе посмотреть — там все запросы к БД без использования QC написаны. Более того, SQL, который там был раньше — мутнее и сложнее. Особенно весело с запросом, обновляющим агрегаты — трехстраничное сиквельное чудовище превратилось в 60 хорошо читаемых строк.
А все потому что проектировщики SQL допустили ряд грубых ошибок в его дизайне. И это, заметь, люди, которые неплохо представляли то, чем они занимаются. Что же получится из под пера кучи ньюбов, пусть и вооруженных прекрасным инструментом для создания парсеров и анализаторов — я представляю себе с содроганием.
Z>Ты не встречал проблем, когда создана кривая библиотека, используемая повсеместно, а создатель уволился? И единственный выход, переписать все?
Масштаб проблем несколько разный. Библиотеку я в полуавтоматическом режиме почистить могу, где то вставляя временные подпорки (не заморачиваясь никакими языкостроительными тулами). А что делать, когда кастомный DSL надо сильно переделать или вообще выкинуть?
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Ziaw, Вы писали:
Z>Я хотел сказать, что умные люди реализовали SQL в своих СУБД, остальные не выжили.
Осталось заметить, что, в итоге, все выжившие более менее поддерживают единый отраслевой стандарт, а не каждый свой язык изобретает. Надо объяснять почему?
Z>Я выделил основную проблему. Потому и проще, что нет пока адекватных инструментов для создания DSL. Но это проблема не DSL, а неразвитости инструментов.
Единый универсальный язык всегда будет выигрывать в плане инструментального оснащения, какие бы замечательные тулы не существовали.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Масштаб проблем несколько разный. Библиотеку я в полуавтоматическом режиме почистить могу, где то вставляя временные подпорки (не заморачиваясь никакими языкостроительными тулами). А что делать, когда кастомный DSL надо сильно переделать или вообще выкинуть?
Ну что за демагогию ты опять разводишь.
Откуда ты взял, что ДСЛ ради мелких изменений нужно выкидывать?
Точно так же спокойно подчищается. А если там такой песец что нужно всё выкинуть, то тебе и с библиотекой придется всё выкинуть.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, AndrewVK, Вы писали:
AVK>Осталось заметить, что, в итоге, все выжившие более менее поддерживают единый отраслевой стандарт, а не каждый свой язык изобретает. Надо объяснять почему?
Там от SQL только синтаксис одинаковый.
AVK>Единый универсальный язык всегда будет выигрывать в плане инструментального оснащения, какие бы замечательные тулы не существовали.
Подсветка, навигация, автокомплит и переименование получаются вообще автоматом.
А это 80% потребностей. С форматированием сложнее. Но и там не так уж и много придется написать.
А более сложные вещи для 99% ДСЛ и не понадобятся никогда.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
Z>Если есть DSL, то он должен быть проще чем вызов методов. Поэтому учить его должно быть не сложнее, чем изучать семантику методов. Иначе он обычная ошибка проектирования и доставляет проблем столько же сколько любая другая ошибка проектирования.
Ага, а вот это point. Т.е. мой пример с кастомным синтаксисом scalatest, не дающим ничего по сравнению со старым тупым junit-овским testX() {} — это проблема scalatest ("заставь дурака богу молиться"), заюзавшим DSL-и там, где не надо.
И хотя такая постановка ответа сразу резко сужает область применения DSL-ей с "а давайте забабахаем!" к "а нафига оно нам надо?", но проблемы тут не вижу (для меня языки общего назначения смысл-таки имеют).
Re[15]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, Ziaw, Вы писали:
D>>Наоборот: в первом случае ничего не надо знать, т.к. это стандартный синтаксис вызова метода. В крайнем случае можно Ctrl+Click по имени метода и попадаем в его определение.
Z>В общем случае не попадаем, мы ведь не знаем точно тип a. Я правильно понимаю, что основная претензия к DSL свелась к отсутствию поддержки Ctrl-Click?
В основном я долблю в нежелание помнить новый синтаксис вместе с новой семантикой. Но ты ниже по этому поводу мне мозги прочистил
. Но в данном случае я ещё имею в виду ненависть по отношению ко всякой boilerplate-магии (e.g. аспекты, а в данном случае и макросы), в которую приходится вникать, чтобы понять, как оно работает. Зачастую эта магия на порядки сложнее не только, чем тот код, который её использует, но и чем аналогичный по функционалу код, который обошёлся без неё. А изучать её при отладке частенько приходится приходится.
D>>1. Может быть, там какой-нибудь бред в духе #define true false в реализации, переворачивающий весь этот "естественный язык" с ног на голову.
Z>Если начинать говорить про бред могу рассказать, как сделать, чтобы метод Insert начал очищать список. Но ты ведь и сам это прекрасно знаешь, зачем приводить такие аргументы?
Гыгы, уел. Но я имел в виду, опять же, boilerplate-магию. В тех же макросах можно прикрутить другую семантику к синтаксису вызова метода (и вроде бы даже в каких-то простеньких макросах так и делали — а это уже тот самый #define true false), а без макросов вызов метода — это вызов метода и ничего более.
D>>2. Я же не могу, прочитав эту естественную и возрадовавшись, начать писать вообще весь код в свободном стиле: "store sum of a and b to c".
Z>Конечно не можешь. Точно так же не можешь начать писать a.MakeTheUniverseWorkForMe(), узнав синтаксис вызова метода и не затрудняя себя изучением контракта a.
Хм. Ну тут WolfHound уже подключился и сказал, что code completion он для макросов в Nemerle даёт автоматом, так что тут ок.
Re[19]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
AVK>>Осталось заметить, что, в итоге, все выжившие более менее поддерживают единый отраслевой стандарт, а не каждый свой язык изобретает. Надо объяснять почему? WH>Там от SQL только синтаксис одинаковый.
Этого мало? Ну и не только синтаксис — семантика всех конструкций тоже идентична.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, dimgel, Вы писали:
D>А можно поподробнее? (Помню ещё сто лет назад сказанное Синклером, что накосячили в угоду "естественноязыковости", но тоже без деталей).
Это я писал, а не Синклер. Что конкретно тебя интересует? Ошибки, собственно, две основных — попытка сделать язык близким к естественному английскому, что привело к тяжеловесному индексу, и крайняя бедность средств декомпозиции, из-за чего копипаста в сиквеле цветет махровым цветом.
... << RSDN@Home 1.2.0 alpha 5 rev. 66 on Windows 8 6.2.9200.0>>
Здравствуйте, Ziaw, Вы писали:
Z>Здравствуйте, Mamut, Вы писали:
M>>Я об этом и говорю. Никакого «обычно» не будет. Он будет документирован не лучше и не хуже, чем любой другой код. Хотя, учитывая, что это будет domain-specific language, то будет документирован еще хуже, так как в условиях «о, у нас домен, давай колбасить DSL» никто не будет выписывать весь синтаксис, семантику и т.п.
Z>Непонятно о чем мы спорим тогда. Люди часто не документируют код. При этом иногда получается грамотный и читабельный код, который легко поддерживать, а иногда макаронный и нечитабельный. Это ортогонально тому, DSL они пишут или библиотеку.
Z>Когда ты читаешь код a.Insert(b) и insert b into a у тебя примерно одинаково информации, для понимания того, что происходит. Но в первом случае тебе надо знать соглашения, чтобы понять, что происходит, а во втором не нужно.
Вот реальный пример, надо без документации сказать в чем разница между "b render a" , "a render b" и "render a b"
Валяй, полагаю, раз это дсл, то для тебя не составит труда рассказать в чем мулька.
Z>DSL от аналогичной библиотеки отличается только тем, что у них разные синтаксисы. Но тот или другой все равно придется учить. И в каких-то предметных областях DSL получается проще чем родной синтаксис языка.
Синтаксис это ерунда. В библиотеку очень легко заглянуть, а дсл это черный ящик и собственно черный ящик большей частью непригоден в софтостроении.
Re[18]: А при чем тут DSL? (в продолжении темы о языках общего назначения)
Здравствуйте, WolfHound, Вы писали:
AVK>>Единый универсальный язык всегда будет выигрывать в плане инструментального оснащения, какие бы замечательные тулы не существовали. WH>Подсветка, навигация, автокомплит и переименование получаются вообще автоматом. WH>А это 80% потребностей. С форматированием сложнее. Но и там не так уж и много придется написать. WH>А более сложные вещи для 99% ДСЛ и не понадобятся никогда.
Для дсл нужен непосредственный доступ к модели, для изучения, исследования, оптимизации и тд, иначе будет как с SQL, большинство использует "по рецептам", малая часть думает что знает, и только ничтожная действительно знает SQL.
С регэксами тож самое, перестал пользоваться на время — все забыто и надо снова документацию перечитывать.
Т.е. нужен не дсл, а четкая прозрачная модель с хорошим апи.
Но я имел в виду, опять же, boilerplate-магию. В тех же макросах можно прикрутить другую семантику к синтаксису вызова метода (и вроде бы даже в каких-то простеньких макросах так и делали — а это уже тот самый #define true false), а без макросов вызов метода — это вызов метода и ничего более.
