Здравствуйте, VladD2, Вы писали:
VD>Покури на досуге Nemerle и уверен, что твое мнение резко изменится.
Это не аргумент. Вон тут кое-кто регулярно Оберон хвалит Да, с виду всё зашибись, а ты этот Немерле в реальном проекте над которым далеко не самые талантливые сыны отчества трудулись использовал?
VD>Что до DSL-ей, то ты их все равно будешь изобретать и использовать так как без них сложные задачи практически не решаются. VD>Вопрос только в том будут ли это чистые и интуитивно понятные решения или эмуляция (например, на базе объектов) кривыми средствами устаревшего языка.
Для убедительности (это не подкол) привёл бы при пример задачи которая с DSL будет решаться интуитивно понятно, а без "за счёт эмуляции на базе объектов кривыми средствами устаревшего языка".
Считать, что уже есть Си++/C#/Java и SQL.
А заодно и трудозатраты на создание DSL, освоение DSL и т.д. хорошобы подсчитать. Я так понимаю, что раз ты защищаешь этот подход, значит использовал его на практике, ну так расскажи мне о реальных цифрах
Здравствуйте, adontz, Вы писали:
A>ИМХО закоренелого консерватора: Я скажу грубость, но статья откровенно фантазёрская.
Когда я переводил эту статью, она была мне интересна чисто теоретически. На данный момент, подход мною используется практически — но не в стиле Дмитриева, а в стиле in-language DSL, о которых говорил eao197
С "высоты" уже практического опыта, могу сказать, что ни с одной из описанных тобой сложностей (пока?) не сталкивался вообще, благодаря малому размеру DSL-ей.
Пример (мой, из текущего проекта):
class Something
#...
data :price, Float, :default => 1.0, :validate => lambda{|val| val >= 0.0}
#...end
(это все, что нужно для описания поля — по этому описанию создается геттер, сеттер, валидатор, инициализатор, загрузка из БД, выгрузка в БД).
Еще пример: тулза под названием rake — это make на Ruby in-language DSL, отличное описание, почти не требующее знания Руби, сделал Фаулер:
(читается "задача main требует выполнения задач errata, articles; файл eaaErrata.html получается из файла eaaErrata.xml выполнением таких-то действий; задача errata требует получения файла eaaErrata.html"
То есть — 2-3 новых "ключевых слова" + "самоописующий" синтаксис (требует очень гибкого базового синтаксиса — динамический Ruby и статический Nemerle этому условию удовлетворяют, не говоря уж о классических Lisp/Smalltalk) — и voila.
Это just works в реальной жизни.
Здравствуйте, adontz, Вы писали:
A>Для убедительности (это не подкол) привёл бы при пример задачи которая с DSL будет решаться интуитивно понятно, а без "за счёт эмуляции на базе объектов кривыми средствами устаревшего языка". A>Считать, что уже есть Си++/C#/Java и SQL.
Вообще говоря, любое создание иерархии классов (или набора функций), отражающих предметную область — и есть создание DSL'я (о чем вполне однозначно говорит Дмитриев в статье). Просто мы это "так не называем".
То есть вот это — тоже DSL (надуманный пример на несуществующем языке):
window = new Window
button = new Button
button.size = (100, 25)
button.caption = 'WTF?'
window.layout(button)
Другое дело — что Дмитриев считает необходимым создать кучу визуальных тулзов, явно поддерживающих такой подход; а мы с Владом внезапно сошлись на том, что достаточно одного языка с ОЧЕНЬ выразительным синтаксисом.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Другое дело — что Дмитриев считает необходимым создать кучу визуальных тулзов, явно поддерживающих такой подход;
ИМХО это не эффективный подход. Как ни смешно, но редактируя формочки .Net мне зачастую проще и быстрее покопаться в файле Designer.cs, чем щёлкать мышью.
ЗХ>а мы с Владом внезапно сошлись на том, что достаточно одного языка с ОЧЕНЬ выразительным синтаксисом.
А, ну я тут с вами тоже соглашусь, но я ещё не помню случая, чтобы плюсы доставались без минусов. Простой пример шаблоны vs дженерики. Шаблоны в конечном итоге элементарно удобнее когда дело касается вызова операторов или даже функций о которых известно лишь имя и число параметров. Выразительность потрясающая, возможности огромные, но отладка этого добра не самое приятное занятие. А дженерики? Убожество убожеством, Никаких существенных проблем, кроме проблемы приведения типов они не решили. Ну а с другой сторны и хлопот с ними на порядок меньше.
Nemerle это чудесно пока на нём пишете ты с Владом (может и мне присоединиться? ), ну а когда на нём будет писать Вася Пупкин? Вот ведь в чём вопрос. Можно напридумывать кучу гениальных вещей, но до промышленного использования доходят не гениальные идеи, а общепонятные.
Здравствуйте, adontz, Вы писали:
ЗХ>>Другое дело — что Дмитриев считает необходимым создать кучу визуальных тулзов, явно поддерживающих такой подход;
A>ИМХО это не эффективный подход. Как ни смешно, но редактируя формочки .Net мне зачастую проще и быстрее покопаться в файле Designer.cs, чем щёлкать мышью.
Да вот фиг его знает. Люды кажуть, что, к примеру, IDE, поддерживающая сложный рефакторинг, на порядок увеличивает продуктивность. Я там ниже в треде сослался на статью Фаулера — так вот он, в том числе, пишет и о том, насколько нужны визуальные тулзы.
ЗХ>>а мы с Владом внезапно сошлись на том, что достаточно одного языка с ОЧЕНЬ выразительным синтаксисом.
A>Nemerle это чудесно пока на нём пишете ты с Владом (может и мне присоединиться? ),
Я не пишу на Немерле
A>...ну а когда на нём будет писать Вася Пупкин? Вот ведь в чём вопрос. Можно напридумывать кучу гениальных вещей, но до промышленного использования доходят не гениальные идеи, а общепонятные.
Мняяя... аргумент по сути, видимо, верный, но мне малоинтересный — я выбираю только то, чем нравится пользоваться лично мне. Промышленная эффективность — как-то
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Да вот фиг его знает. Люды кажуть, что, к примеру, IDE, поддерживающая сложный рефакторинг, на порядок увеличивает продуктивность. Я там ниже в треде сослался на статью Фаулера — так вот он, в том числе, пишет и о том, насколько нужны визуальные тулзы.
А какая есть визуальная поддержка рефакторинга? Переименовать класс/метод? И сё? Не густо.
Нет, я не против DSL. Например я уже давно набираю структуру БД вот в таком виде
По очень простой причине — так легче править руками. DDL SQL очень громоздкий, когда надо просто понять какие у нас будут таблицы и столбцы. Делать это в Visio и даже Excel не удобно — я пытался. Удобнее в Visual Studio открыть текстовый файл и писать вот в таком вот формате. Но это моя персональная фенечка, которая удобна лично мне. Я в таком виде структуру БД никому не отдам и уж тем более не потребую, чтобы мне её приносили в таком виде.
ЗХ>Мняяя... аргумент по сути, видимо, верный, но мне малоинтересный — я выбираю только то, чем нравится пользоваться лично мне. Промышленная эффективность — как-то
А мне летать, а мне летать, а мне летать охота...
Ну раз такие аргументы не интересны, других у меня и не было
Здравствуйте, adontz, Вы писали:
A>Это не аргумент. Вон тут кое-кто регулярно Оберон хвалит Да, с виду всё зашибись, а ты этот Немерле в реальном проекте над которым далеко не самые талантливые сыны отчества трудулись использовал?
А это и не аргумент. Это предложение и предположение. В общем, ты покури, а там расскажешь прав я оказался или нет.
Обещаю, что время будет потрачено не зря и проведено с интересом.
VD>>Что до DSL-ей, то ты их все равно будешь изобретать и использовать так как без них сложные задачи практически не решаются. VD>>Вопрос только в том будут ли это чистые и интуитивно понятные решения или эмуляция (например, на базе объектов) кривыми средствами устаревшего языка.
A>Для убедительности (это не подкол) привёл бы при пример задачи которая с DSL будет решаться интуитивно понятно, а без "за счёт эмуляции на базе объектов кривыми средствами устаревшего языка". A>Считать, что уже есть Си++/C#/Java и SQL.
Таких задач масса. Вот тебе ради хохмы пример отличной пенисометрии демонстриующей силу ДСЛ-ей: Версия 0.04
это тоже в общем-то ДСЛ, но язык менее выразительный и все проблемы недоДСЛей вылезают очень сильно. Сравни декларацию типов, да и оцени использование физических литералов.
Из других примеров... Как тебе строки со слйсами в стиле Руби или Перла:
$"Summa = $(a + b)..."
A>А заодно и трудозатраты на создание DSL,
Трудозатраты зависят от языка. Если пытаться создавать ДСЛ-и на С++, то конечно проблем не оберешся. Затраты могут сильно перевешивать бенефиты и реальное приемущество будет получено только в очень универсальных случаях. Но если есть нечто вроде макросов Немерле, то создание ДСЛ-ей становится сравнимым с созданием библиотеки.
A>освоение DSL и т.д. хорошобы подсчитать.
Этот скепсис от непонимания чем отличается ДСЛ от ЯП общего назначения. ДСЛ — это очень простой язык решающих ограниченный набор задач предметной области (ДСЛ — язык специфичный для предметной области).
ДСЛ-и очень просты в освоении и менее подвержены ошибкам, так как не универсальны, что позволяет ограничивать их только корректными описаниями (все некооректное должно быть синтаксически не верным).
A> Я так понимаю, что раз ты защищаешь этот подход, значит использовал его на практике, ну так расскажи мне о реальных цифрах
Ты тут как-то набросился на мою статью о конфигурации. Так вот как раз она описывала ДСЛ-подход средствами ЯП не преднозначенного для разработки ДСЛ-ей.
А вообще, ДСЛ — это можно сказать отдельная парадигма. Прогрмму можно представить как набор ДСЛ-ей и описание на них самой программы. При таком подходе объем кода резко сокращается, а его надежность увеличивается.
Кстати, SQL — это ДСЛ дотсупа к реляционным данным. Так что ты и сам не раз использовал ДСЛ-и, но не думал о них как парадигме. Если же осознать эту парадигму, то твой арсенал может резко увеличиться и ты сожешь решать многие задачи проще.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Другое дело — что Дмитриев считает необходимым создать кучу визуальных тулзов, явно поддерживающих такой подход; а мы с Владом внезапно сошлись на том, что достаточно одного языка с ОЧЕНЬ выразительным синтаксисом.
Да уж. Не часто мы сходимся на 100%, так что в этом однозначно что-то есть.
Кчтати, я бы сказал, что даже не с выразительным синтаксисом, а с выразительными средствами расширения синтаксиса и контроля результата. Вот, например, базовый синтаксис Немерле очень ограничен. Но маросы позволяют очень гибко расширять язык. В итое язык становится очень выразительным, хотя он по базовой локоничности пожалуй проиграет Оберону.
Пользуясь случаем передаю привет С.Губанову.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>ИМХО это не эффективный подход. Как ни смешно, но редактируя формочки .Net мне зачастую проще и быстрее покопаться в файле Designer.cs, чем щёлкать мышью.
Забавно, что код генерируемый дизайнерами тоже является ДСЛ-ем и даже имеет свой интерпретатор и не полностью совместим с C# или VB. А сам дизайнер это визаулизатор этого ДСЛ-я и по совместительству свой ДСЛ.
В общем, ДСЛ — это больше парадигма (образ видения программы), чем кокретное вополщение.
A>А, ну я тут с вами тоже соглашусь, но я ещё не помню случая, чтобы плюсы доставались без минусов. Простой пример шаблоны vs дженерики. Шаблоны в конечном итоге элементарно удобнее когда дело касается вызова операторов или даже функций о которых известно лишь имя и число параметров.
Боюсь, что для этого куда удачнее использовать функциональные типы. Опять же погляди на Немерле и поймешь, что и тут С++ не лучший пример.
A> Выразительность потрясающая, возможности огромные, но отладка этого добра не самое приятное занятие. А дженерики? Убожество убожеством, Никаких существенных проблем, кроме проблемы приведения типов они не решили. Ну а с другой сторны и хлопот с ними на порядок меньше.
Дык, дженерики — это хорошее решение конкретной проблемы. В отличии от С++-шаблонов они просто неспособны решать другие задачи.
Так вот хороший ДСЛ — это тоже "хорошее решение конкретной проблемы".
A>Nemerle это чудесно пока на нём пишете ты с Владом (может и мне присоединиться? ), ну а когда на нём будет писать Вася Пупкин? Вот ведь в чём вопрос. Можно напридумывать кучу гениальных вещей, но до промышленного использования доходят не гениальные идеи, а общепонятные.
Васи Пупкину можно дать в руги уже результат труда квалифицированного программиста. Макросы Немерле — это сборки подключаемые через референсы (как простые сборки, да они ими и являются). Так что создать макрос внутри проекта невозможно. И тот кто отвечает за проект может легко контролировать какие макросы используются и кто их создает.
К тому же в отличии от С++ Немрле несравнимо проще. Да и ошибок дизайна в языке куда меньше. Для обобщенного кода используются те же дженерики. А для более хитрых вещей макросы. Сам же язык даже более безопасен и прост чем C#.
ЗЫ
В общем, я последний месяц его изучаю и не перестаю удивляться насколько грамотно он спроектирован. Если бы не проблемы вроде отсутсвия полноценной поддержки IDE, ошибки и недоработки в компиляторе и отсуствие хорошей документации (хотя над этим мы уже и сами работаем) я бы вообще забыл про другие языки. В общем, я просто в восторге от этого языка. Мое мнение — это реальный прорыв в мэйнстрим-языках! Это то что я так долго искал.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Сергей Дмитриев, Зверёк Харьковский (перевод), Вы писали:
A> Надёжность A>Не секрет, что даже самый простой язык сложно учить. Базовая часть SQL один из самых простых языков, но даже с её помошью можно наворотить весьма и весьма трудноотлаживаемые конструкции. Нельзя создать абсолютно дуракозащищённую систему. Даже самые передовые промышленные языки типа C# имеют свои грабли. Где же гарантия, что DSL'ы будут и достаточно мощными, и лишёнными граблей? А нет такой гарантии. Почему многие используют MFC? Библиотека-то так себе. потому что есть огромный опыт использования и если случилось что-то плохое, то скорее всего ты не первый и известно как с этим бороться. А это, заметьте, в рамках Си++, всего одна библиотека. А если новый язык? A> [поскипано]
Надёжность
Не секрет, что даже самую простую библиотеку сложно учить. Базовая часть StandartIOLib одная из самых простых библиотек, но даже с её помошью можно наворотить весьма и весьма трудноотлаживаемые конструкции. Нельзя создать абсолютно дуракозащищённую систему. Даже самые передовые промышленные языки типа Algol68 имеют свои грабли. Где же гарантия, что библиотеки будут и достаточно мощными, и лишёнными граблей? А нет такой гарантии. Почему многие используют PDP1? Машинка так себе. потому что есть огромный опыт использования и если случилось что-то плохое, то скорее всего ты не первый и известно как с этим бороться. А это, заметьте, в рамках , всего одна машина. А если новая библиотека?
......................
Библиотеки
В результате, если раньше человек учил один ассемблер и грабли одной машины, то теперь он будет учить язык высокого уровня да ещё 5-6 библиотек и грабли 5-6 библиотек. Насколько реально заставить среднего специалиста учить 5-6 библиотек? А вообще много ли программистов действительно (со всеми граблями) знает больше 3-4 библиотек?
..................
На каждую используемую библиотеку нужно минимум 2-3 человека которые будут её знать, а иначе проект будет очень зависим от конкретных личностей. А если таких библиотек 10? Причём если набор комнанд процессора 8086 всем известен, то нанять человека знающего библиотеку внутреней разработки просто нельзя. Значит увеличивается время ввода в курс дела нового сотрудника. Кроме того библиотеки внутренней разработки это такая штука у которой есть автор и все остальные. И когда уходит автор, новый автор начинает её переделывать под себя. Внутренние разработки всегда имеют личностный и проектный налёт и очень редко действительно универсальны.
--------------------------------
A>Должны быть очень серьёзные причины чтобы заставлять людей учить новый язык (я думаю изучение языка программирования по сложности сопоставимо с человеческим языком). У нас, помимо языка общего назначения — русского, есть не так уж много DSL'ей. Математические знаки (физика пользуется математическими знаками) и химические. Других я и не припомню. Если нам в жизни хватило всего 3х языков, зачем их плодить в программировании и называть это прогрессом, когда вместо разработки продукта у нас будет вавилонское столпотворение?
А если серьёзно, вы так говорите, как будто DSL будут такие же сложные как языки программирования, они в большинстве случаев намного проще и соотвественно всё что вы сказали "слегка" преувеличено. Я уже приводил пример, миниязыки в Unix сообществе используяться постоянно — чистый LOP, никто не жалуеться — учит. Или ActiveRecord и Hibernate чем не DSL?
Я скажу грубость, но статья откровенно фантазёрская.
Ты не только консерватор, ты еще и догматик
Сам себе создал дракона, сам же его и убил.
DSL — это не язык в том же понимании, что и C++, и даже не SQL. Это намного меьше, и в то же время — больше. Типичный DSL не обязательно должен отвечать критерию о Тьюринг-полноте (и даже лучше, если он не будет ему отвечать). Он должен всего лишь просто и эффективно решать одну очень узкую и ограниченую задачу. Для понимания сути DSL лучше подумать о регулярных выражениях или XPath.
SQL, конечно, когда-то задумывался как DSL, но со временем к нему приделали императивные расширения синтаксиса и кучу других нестандартных расширений, которые извратили изначальную идею. [off] Да и его стандартный синтаксис далек от идеала, если хорошо подумать. Авторы слишком много задумывались об идеологии, и слишком мало о практике.[/off]
Ситуация, когда разные разработчики решают одну и ту же задачу разными DSL, полностью аналогична ситуации, когда один разработчик использует для построения GUI Qt, а другой wxWindows. И решается она такими же средствами, то есть при помощи стальной линейки или розг — в зависимости от вкусов руководителя проекта
VD>это тоже в общем-то ДСЛ, но язык менее выразительный и все проблемы недоДСЛей вылезают очень сильно. Сравни декларацию типов, да и оцени использование физических литералов.
Сравнил, оценил. Слабенько. То есть внешне прикольно, а вот на кто на деле использует разные системы мер в одной программе? Зато как я понял так не сделать
length_t x = 3;
length_t y = 5;
length_t z = 9;
volume_t v = x * y; // упс, забыли z, нихрена не скомпилируется.
Ладно забили, идею, что DSL это абстракция, а не сущность я уже понял
VD>Трудозатраты зависят от языка. Если пытаться создавать ДСЛ-и на С++, то конечно проблем не оберешся.
Например boost:spirit?
VD>Этот скепсис от непонимания чем отличается ДСЛ от ЯП общего назначения. ДСЛ — это очень простой язык решающих ограниченный набор задач предметной области (ДСЛ — язык специфичный для предметной области).
DSL это синтаксически очень простой язык. Влад, даже в пределах оператора SELECT можно такого наворотить.... А весь синтаксис с примерами помещается на 5 страниц.
VD>Ты тут как-то набросился на мою статью о конфигурации.
Как видишь, я набрасываюсь на все статьи, так что запомни — это не личное, я просто злой и вредный вообще.
VD>Так вот как раз она описывала ДСЛ-подход средствами ЯП не преднозначенного для разработки ДСЛ-ей.
Аээээ ну так вообще любой конфигурационный файл давай обзовём DSL'ем. А-а-а-а DSL'и нас окружили, они нападают
За стёб 5+
CP>А если серьёзно, вы так говорите, как будто DSL будут такие же сложные как языки программирования, они в большинстве случаев намного проще и соотвественно всё что вы сказали "слегка" преувеличено.
Проблема в том, что если ты ошибся в самой реализации языка, и на нее уже написал код, то при изменении оного получишь на порядок больше проблем чем при изменении библиотеки(которая обладает ясным интерфейсом). Поэтому стоимость ошибки в языке значительно больше чем стоимость ошибки в библиотеке.
Пока нету нормального автоматизированного рефакторинга, сравнивать с библиотеками не стоит.
Здравствуйте, adontz, Вы писали:
A>Это не аргумент. Вон тут кое-кто регулярно Оберон хвалит Да, с виду всё зашибись, а ты этот Немерле в реальном проекте над которым далеко не самые талантливые сыны отчества трудулись использовал?
Не в первый раз я слышу сравнение обсуждения Nemerle с "обсуждением" Оберона. И всё-таки хочу заметить, что сторонники Nemerle на форуме всё же стараются аргументированно отстаивать свою точку зрения (например — приводить
А вот что мне как раз не нравится, так это странные вроде_бы_как_оппоненты, которые заявляют, что Nemerle есть очередная туфта, даже не удосужившись его попробовать (что совсем несложно) хотя бы на небольшом проектике. Нет, ничего личного, — я вообще говорю...
Здравствуйте, adontz, Вы писали:
A>Сравнил, оценил. Слабенько. То есть внешне прикольно, а вот на кто на деле использует разные системы мер в одной программе?
Сравнивать предлагали реализацию на C++ и Nemerle. Понятно, что эта библиотека никому нафик не нужна (и тем не менее, тут на форуме утверждали, что на Nemerle она не решается — этот факт также подтолкнул меня к написанию решения на Nemerle ).
A>Зато как я понял так не сделать A>
A>length_t x = 3;
A>length_t y = 5;
A>length_t z = 9;
A>volume_t v = x * y; // упс, забыли z, нихрена не скомпилируется.
A>
Плохо понял — в таком случае именно что не скомпилируется (у величин разные размерности, и проверка этого будет выполняться на этапе компиляции; собственно, задача библиотеки и была вынести подобные проверки на этап компиляции), чего и требуется Ты бы попробовал хоть для начала...
Здравствуйте, adontz, Вы писали:
A>Сравнил, оценил. Слабенько. То есть внешне прикольно, а вот на кто на деле использует разные системы мер в одной программе? Зато как я понял так не сделать A>
A>length_t x = 3;
A>length_t y = 5;
A>length_t z = 9;
A>volume_t v = x * y; // упс, забыли z, нихрена не скомпилируется.
A>
Плохо ты понял... Смотри лучше.
VD>>Трудозатраты зависят от языка. Если пытаться создавать ДСЛ-и на С++, то конечно проблем не оберешся. A>Например boost:spirit?
Жутик еще тот... а если вспомнить boost::lambda...
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, adontz, Вы писали:
A>Сравнил, оценил. Слабенько.
Слабенько? И что слабенько? Сравни чистоту описания и возможность использования просто таки литералов физ.величин с тем что получается на С++.
По-моему, разница настолько очевидна, что и говорить не о чем.
А ведь С++-решение использует почти 100% языка, то есть идет на грани возоможностей языка. Меж тем результат получается не очень замечательный. Описание физ.величин запутанное и непонятное. О физ. литералах вообще речи не идет. А сообщения об ошибках?
Меж тем у Немерла есть огромный запас прочности. Так что ты тут явно не прав.
A> То есть внешне прикольно, а вот на кто на деле использует разные системы мер в одной программе? Зато как я понял так не сделать A>
A>length_t x = 3;
A>length_t y = 5;
A>length_t z = 9;
A>volume_t v = x * y; // упс, забыли z, нихрена не скомпилируется.
A>
A>Ладно забили, идею, что DSL это абстракция, а не сущность я уже понял
Ты почитай тему сначала, и за одно почитай тему на которую ссылается оная. Так как раз и идет речь о том, что во время компиляции осуществляется контроль над преобразованием величин и их корректным использованием.
Так то ты просто не понял сути.
VD>>Трудозатраты зависят от языка. Если пытаться создавать ДСЛ-и на С++, то конечно проблем не оберешся.
A>Например boost:spirit?
Да, например. Только Спирит тоже идет на пределе возможностей С++. По сему имеет кучу ограничений и проблем (как например плохая диагностика ошибок и невозможность отладки метакода).
Меж тем Немерле позволяет решить подобную задачу вообще без ограничений.
A>DSL это синтаксически очень простой язык. Влад, даже в пределах оператора SELECT можно такого наворотить.... А весь синтаксис с примерами помещается на 5 страниц.
SQL — это пример границы между ДСЛ и полноценным языком. Потому он так сложен.
A>Как видишь, я набрасываюсь на все статьи, так что запомни — это не личное, я просто злой и вредный вообще.
Ну, ну... Ты себя оговаривашь. Что-то критики С++-статей от тебя не много.
VD>>Так вот как раз она описывала ДСЛ-подход средствами ЯП не преднозначенного для разработки ДСЛ-ей.
A>Аээээ ну так вообще любой конфигурационный файл давай обзовём DSL'ем. А-а-а-а DSL'и нас окружили, они нападают
Дык так оно и есть. Просто те кто не систематизировал свои взгляды этого пока не замечают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Да, с виду всё зашибись, а ты этот Немерле в реальном проекте над которым далеко не самые талантливые сыны отчества трудулись использовал?
уже практического опыта, могу сказать, что ни с одной из описанных тобой сложностей (пока?) не сталкивался вообще, благодаря малому размеру DSL-ей.
), ну а когда на нём будет писать Вася Пупкин? Вот ведь в чём вопрос. Можно напридумывать кучу гениальных вещей, но до промышленного использования доходят не гениальные идеи, а общепонятные.
