Здравствуйте, alex_public, Вы писали:
_>И мне не кажется что данная задача чем-то сложная. В данном случае решение MS мне не кажется правильным, но абсолютно не удивляет — оно же укладывается в их давнюю традицию. Те же rc файлы в прошлом и т.п. Т.е. это их давняя стратегия. А стратегии с кодогенерацией я у них вообще не помню — это традиции других.
Да ладно. Кодокенерация у них встречается частенько. Для тех же ресурсов дотнета они генерируют классы-обертки.
Вопрос только в катастрофически низком уровне этой генерации.
_>Хыхы, а тот наш редактор как раз генерит код сразу на нескольких языках. )))
У них тоже. Только вот подключить свой довольно не просто. Кроме того уверен, что наворотов в вашем редакторе существенно меньше. А стало быть и проблем.
В любом случае, если имеет место генерация в разные языки, то имеет место и ДСЛ. И МС, и вы создаете некую модель в памяти и правила ее изменения. И уже эту модель сериализуете в код (или еще куда-то). Единственное что — эту модель вы не записываете на диск в исходном виде. Вот и все.
_>Я в какой-то степени про это и говорю. Продумывание синтаксиса нового языка — это всё же определённая задача, которую не профи (в dsl строение) не так уж и просто решить.
+1
_>А вот такие инструменты по сути выполняют роль DSL, но при этом их создатели вообще не тратили время на продумывание синтаксиса и т.п.
А вот это заблуждение. Время на синтаксис может и не тратит. Но потом он тратит время на выцарапывание своего ДСЛ-я из конструкций ЯОН. Так что синтаксис по сути есть. Но он более корявый.
Я бы сделал следующую сортировку по степени убывания выразительности и удобства:
1. ДСЛ с продуманным синтаксисом и семантикой.
2. ДСЛ средствами ЯОН — модель с которой возятся универсальными средствами.
3. Прямой долбеж кода на ЯОН без выделения ДСЛ-ей и моделей.
Третий способ приемлем только для разного рода вычислительных задач и некоторых других не объемных задач.
Второй способ является по сути ДСЛ-ем для бедных. Он имеет кучу недостатков по сравнению с первым но предоставляет похожие на первый пункт уровни абстрагирования.
Первый же вариант хрош всем кроме того, что ДСЛ-и очень трудно разрабатывать средствами современных популярных ЯОН и почти невозможно качественно встраивать в популярные ЯОН-ы.
Вот это мы и хотим исправить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.
В 1Эс есть джоины?
Вот в Парусе их вроде нет. Это и есть основной смысл их ДСЛ-я (возможно не единственный).
ДСЛ вообще не обязан преобразоываться во что-то уж совсем отличное от оригинала. Трансляция из некоторого объектного языка запросов в SQL — вполне приемлемый вариант.
То что он не дает какого-то ошеломляющего упрощения еще не значит, что он не полезен. Процедуры ведь тоже не всегда делают море работы. Но вместе они и порождают решение нужного уровня и качества.
К тому же от ДСЛ могут быть и другие преимущества. Например, его можно транслировать в разные диалекты SQL-я.
VD>>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ. G>Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается. G>SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.
Он был и есть таким всегда. PL/SQL — это процедурное расширение SQL. По сути это ЯОН. На нем даже десктопные приложения можно писать (в Оракл Формс). Точно так же процедурным расширением является и TSQL.
Оба они являются примером встраивания ДСЛ-я в ЯОН. Вот только ЯОН довольно хреновые по сравнению с современными аналогами.
По тому мы и говорим о том, что лучше брать топовые ЯОН и внедрять в них нужные ДСЛ-и.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mrTwister, Вы писали:
T>А по каким критериям ты относишь то или иное API к ДСЛ и к "ручному кодированию"? Если мы напишем класс, название которого соответствует некоторой доменной сущности, а методы соответствуют доменным операциям, то код, написанные с использованием этого класса является DSL? Скорее всего ты ответишь нет, но почему тогда Criteria API из hibernate является DSL?
По наличию модели. Скажем если я вижу парсер рекурсивного спуска, то это лобовое решение. Если же я вижу комбинаторый парсер (который в итоге так же может выраждаться в рекурсивный спуск), то это уже ДСЛ, но эмулируемый средствами ЯОН.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
G>Только все это 1-в-1 мапится на SQL, только имена переписываются.
Во-первых не совсем 1 в 1. Во-вторых — ну и что?
AVK>>Ну вот что в тестах, к примеру, валяется: G>Так это SQL. А где его собственный DSL?
Это не SQL, это собственный язык запросов, смотри внимательнее.
G>>>В чем лучше? AVK>>Во всем. G>Ага, грузины лучше чем армяне G>Аргументация на уровне детсада.
Какой вопрос, такой и ответ.
AVK>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать. G>Тогда давай формализуем понятие мощности.
Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, VoidEx, Вы писали:
VE>Только ты ему одну крайность кидаешь в качестве аргумента, а он тебе другую. Точнее говоря, ты опираешься на крайность (берёшь один из самых вырожденных случаев DSL) в качестве доказательства того, что DSL оправданы всегда, а это не так.
Абсолютно согласен. Но в отличии от библиотечного подхда ДСЛ-льный себя пока не исчерпал. Не всегда, конечно, но он позволяет добиться высокого повышения уровня абстрации.
Ну, а сложность разработки ДСЛ-ей во многом определяется отсутствием достойных средств разрабокти и нитеграции в язык (для внутренних ДСЛ-ей). Так что решив эту проблему (упростив разработку и нитеграцию ДСЛ-ей) можно сделать ДСЛ-подход более досупным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.
VD>В 1Эс есть джоины?
1) inner — легко "select * from a,b where a.key = b.key"
2) left outer — табличные части
VD>Вот в Парусе их вроде нет. Это и есть основной смысл их ДСЛ-я (возможно не единственный).
Смысл DSL в том чего что-то нет? Тогда зачем он нужен?
Это ведь можно и без создания DSL проверить.
VD>>>SQL тоже рассматриваем, так как он классический ДСЛ. Просто он общепринятый ДСЛ. G>>Он был таким лет 20 назад. Если сейчас посмотреть на pl\sql, то DSL его назвать — язык не поворчивается. G>>SQL в версии стандарта 92 года — да, DSL. Но если посчитать сколько в его разработку вложено, но аналогов не найдешь.
VD>Он был и есть таким всегда. PL/SQL — это процедурное расширение SQL. По сути это ЯОН. На нем даже десктопные приложения можно писать (в Оракл Формс). Точно так же процедурным расширением является и TSQL.
Так чистого SQL нету нигде, везде есть эти самые расширения.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Только все это 1-в-1 мапится на SQL, только имена переписываются.
AVK>Во-первых не совсем 1 в 1. Во-вторых — ну и что?
А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен и не может быть примером архиполезности ДСЛ и ненужности ЯОН.
AVK>>>Ну вот что в тестах, к примеру, валяется: G>>Так это SQL. А где его собственный DSL? AVK>Это не SQL, это собственный язык запросов, смотри внимательнее.
А чем от SQL отличается? См выше.
AVK>>>Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать. G>>Тогда давай формализуем понятие мощности. AVK>Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас.
Так ты употребил термин "мощность", видимо без понимания что это такое
Здравствуйте, gandjustas, Вы писали:
G>А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен
Это даже не смешно. Т.е. в 1С сидят идиоты, делающие бесполезные вещи?
AVK>>Это не SQL, это собственный язык запросов, смотри внимательнее. G>А чем от SQL отличается? См выше.
Я выделил. Или ты считаешь, что верхний и нижний запросы абсолютно идентичны во всем, кроме имен полей?
AVK>>Т.е. поспосрим о терминах? Все понятно, можешь не продолжать, я пас. G>Так ты употребил термин "мощность"
Это ТЫ его употребил.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VE>>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#. VD>Если признать что ДСЛ — это мера, то нужно искать новые термины для выражения того же самого.
Для чего именно?
VD>Если же признать, что 1Эс и ВБА — это не ДСЛ, то все становится куда проще. За одно стаовится понятно, что 1Эс — это ЯОН в который гвоздями прибит ДСЛ. А как только это становится понятно, и программисту становится известно о наличии Немерла и Лиспа, то становится понятно и то, что такое решение не более чем ошибка дизайна. Ведь ДСЛ может быть прост библиотекой.
А ты опиши чёткие критерии. Пока что всё, что сказано — только вкусовщина без описания метода измерения.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>А в том что DSL, который приводится в SQL (или другой язык общего назначения) бесполезен AVK>Это даже не смешно. Т.е. в 1С сидят идиоты, делающие бесполезные вещи?
Нет, стоит просто называть веши своими именами. Назовем это переписыванием имен в запросе.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>1C плохой пример — там запросы 1-в-1 транслируются в SQL, только имена переписываются.
VD>В 1Эс есть джоины?
Давным давно в 8ке. Он максимально приближен к нормальному SQL. Правда там куча ограничений (нет переменных запроса (@gthtvtyyfz=Select //), нем множества функций для работы со строками итд. Нет Merge? insert, update, exsists, поле=Select итд). Но в большинстве случаев этого хватает.
Приходится писать прямые запросы в основном для массовых изменений данных.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, VoidEx, Вы писали:
VE>Я думаю, стоит копать в направлении "полноценные ДСЛ-ли позволяют описывать прикладную задачу на более высоком абстракнтом уровне", но не по сравнению с языками общего назначения, а по сравнению с прикладной задачей в другой области. VE>Т.е. если на DSL для вычисления факториала приходится пользоваться терминами той предметной области, под которую он заточен (и вычисление факториала на порядки менее высокоуровнево, чем решение задачи из своей области), то это DSL. Даже если задачу из родной области решить проще на Nemerle. VE>Т.о. главное — нацеленность на одну область.
Идея понятна, но в ней есть заметные дыры.
Например, какой (чего) факториал? В 32 бита влезет факториал аргумента до 12 включительно. Для аргументов от 21 нужна длинная арифметика.
В таком случае "вдруг" окажется, что Python, Erlang и Рапира — языки общего назначения, а C, Java, etc. — DSL'и. Потому что для подсчёта факториала от 21 нужно или реализовывать самому умножение с переносом, или подключать libgmp с аналогами.
VE>Это не чёткая грань, а некоторая мера. В целом, согласен. VE>И если уж признать, что DSL — это мера, а не bool, то спорить про VBA становится проще. Потому что обе стороны могут не спорить, DSL это или нет, а сойтись на том, что он менее DSL, чем SQL, но всё же не такого уж общего назначения, как C#.
Здравствуйте, VladD2, Вы писали:
V>>Факты про то что ни один старап не будет рисковать своим проектом... VD>Вот это ты сейчас хорошо пошутил. У стартапов весь смысл в риске ради возможного поблучения резких конкуретных преимуществ. По сему стартап не желающий рисковать исходно обречен.
А с чего ты решил что количество таких стартапов должно быть больше чем нормальных, желающих просто развиваться и не рисковать своей шкурой?
V>>и как следствие кошельком чтобы проверять выстрелит ли дсл? VD>Кошелек то не их. В этом вся суть .
С чего бы это?
V>> Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл? VD>А зачем менять отлаженный код без надобности? Можно его обернуть в ДСЛ,
Зачем оборачивать в дсл то что уже работает и есть не просит?
V>>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл. VD>Писать ДСЛ-и не должны все кому не лень. А вот использовать и изучать куда легче чем код написанный вручную.
Опять же спорно.
VD>Сейчас основная проблема в ДСЛ-подходе — это сложность разработки и сопровождения ДСЛ-ей, а так же низкое качество получаемых ДСЛ-ей (нет поддержки ИДЕ, низкая скорость, нет контроля типов, нет документации). Если их решить, то ДСЛ будет отличным решением для многих проблем.
Да не будет он решением многих проблем, также как и sql не является решением многих проблем. Максимум что будет, это займёт свою узкоспециализированную нишу, но никак не вытеснит языки общего назначения, по объективным причинам.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, VoidEx, Вы писали:
VE>Ну а ты давай сделай SQL с нуля, сам язык,
Ты так говоришь как будто это что-то сложное.
Если займусь, сделаю как минимум не хуже.
VE>теорию,
Теорий сейчас завались на все случаи жизни.
Их только знать нужно. Причем знания нужны поверхностные. Для того чтобы понять что есть теория которая подходит под задачу и знать где про эту теорию прочитать подробнее.
VE>и поддерживай это всё.
При наличии хороших инструментов это весьма простая задача.
VE>Он толсто намекает на то, что DSL написать — не поле перейти, и очень нередко написать "свой SQL" может оказаться сложнее, чем таки поработать через АПИ.
Вы очень сильно завышает сложность создания ДСЛ.
Это не сложнее чем создать библиотеку.
А при наличии правильных инструментов даже проще, ибо при создании ДСЛ нет очень сложной и противной задачи: Натянуть модель выполнения задачи на язык.
Это очень не просто. И часто просто не реализуемо без серьезных издержек. Которые могут выражаться разными способами. Либо код превращается в говно. Либо все начинает жутко тормозить. А обычно и то и другое одновременно.
Кстати для создания грамотной библиотеки тоже нужно знать теории.
VE>Только ты ему одну крайность кидаешь в качестве аргумента, а он тебе другую. Точнее говоря, ты опираешься на крайность (берёшь один из самых вырожденных случаев DSL) в качестве доказательства того, что DSL оправданы всегда, а это не так.
Я просто показал пример ДСЛя который все знают. Только и всего.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, __lambda__, Вы писали:
___>Зачем учить внутренности библиотеки, в том то и весь смысл библиотек, что нужно лишь знать внешний интерфейс. Черный ящик, декомпозиция, модульность... Это же азбука. Если вам приходится читать внутренний код библиотек, разбираться в том, как она устроена, ты вы явно че-то не то делаете.
Только язык инкапсулирует логику несравнимо лучше, чем любая библиотека.
Давно тебе приходилось читать исходники компилятора, чтобы использовать язык?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Про то, что код на ДСЛ проще понять, поддерживать, развивать и там намного меньше багов я думаю можно даже не заикаться.
При условии, что нет багов в компиляторе. И при условии, что DSL правильно спроектирован. Потому что тут же рядом в разговоре про SQL что-то такое говорится
. И компилятор поддерживать тоже надо. Например, если DSL изменяется/расширяется.
В общем, если бы все было так хорошо, DSL'и были бы везде.
Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.
Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.
Здравствуйте, VladD2, Вы писали:
VD>соображения
Интересное слово. Надо будет запомнить.
VD>Затем, что почти для любой задачи можно придумать свой ДСЛ.
Не почти, а для любой.
VD>При этом никто не отменяет наличия ЯОН-ов и их совместное использование с ДСЛ-ями. Так что с темой я не согласен. Но ЯОН должен гладко интегрироваться с ДСЛ-ями, а лучше — позволять их разрабатывать.
ЯОН можно использовать, только если его модель совпадает с моделью задачи. В этом случае он просто становится, ПОЯ для этой задачи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
VD>Ты и сам знаешь что это не так. В библиотеки нельзя запихать все. Библиотеки не позволяют всегда получать эффективнй код. Ну, и конечно же, многие библиотеки — это ДСЛ-и облаченные в не очень красивую форму и имеющий не очень эффективный рантайм.
И нельзя забывать про то что ДСЛ не позволяет тем которые попроще лезть куда не следует.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
