Здравствуйте, alex_public, Вы писали:
_>Угу, я уже понял что у вас в этом смысле всё круто. Правда только для одной IDE (от использования которой я отказался ещё несколько лет назад). А то я писал про вариант с DSL в обычных IDE.
Ох. Ещё раз.
Найтра на ИДЕ не завязана вообще от слова совсем.
Прямо сейчас есть интеграция в студию и отдельная WPF'ная программа с редактором в котором есть и подсветка и автодополнение и много чего ещё.
Точно так же найтру можно засунуть в любую другую программу.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Так о том и речь. Причём этот DSL очевидно должен быть очень простой. А в тоже самое время первая команда могла параллельно использовать какой-нибудь мегасложный DSL на макросах, для статической проверки каких-то правил в своём коде.
Ох. В случае с найтрой это строго одно и то же.
Только набор макросов разный.
_>А кто мешается сделать так же с динамикой? ) У нас же это всё внутри одного приложения...
Удачи.
_>Да, вот так отлично) Хотя понятно, что любители C# такое не воспримут и захотят только Linq вариант. )))
Линк (особенно если это linq2db) объективно лучше.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Гест, Вы писали:
Г>>Тут, чтобы о чём-нибудь разговаривать, нужно бы согласовать словари.
_>Хорошо, сейчас поясню всё на простейшем примере, основываясь на описанной мною в первом сообщение классификации.
[...]
_>Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б.
Мне кажется, что помимо (естественного для статики, но не базового для разработки вообще) деления на «проверяемое в компайлтайме» и «проверяемое в рантайме» нужно говорить о делении на проверяемое во время разработки и проверяемое в продакшене.
И польза от идеи DSL в принципе — в том, что у нас получается лаконичный код, отражающий предметную область и надёжно проверяемый во время разработки (несмотря на то, что по классификации с точки зрения статики, всё это попадает в одну и ту же «самую неуважаемую» категорию). Пример (часть примера выше):
class User < ActiveRecord::Base
has_many :posts # <- DSL!end
Чем интересна отмеченная строка?
* она сгенерирует некоторое количество кода (методы типа User.add_post, User.remove_post, User.posts.count и т.д.), который скорее всего корректен и оптимален; без этого пришлось бы реализовывать их все вручную и тестировать каждый в отдельности
* она — часть основного языка, и если ты напишешь has many :posts или has_much :posts или has_many posts — тебя поправит конечно не компилятор, но интерпретатор на этапе разработки
* она даёт раннее обнаружение ошибок: например, если таблицы posts не существует в БД или в ней нет ключа для ассоциации — код упадёт сразу при запуске с понятной и читаемой ошибкой (а не в одном из методов в рантайме, в котором ты опечатался в названии таблицы, хотя во всех остальных методах всё верно)
И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.
Здравствуйте, Гест, Вы писали:
Г>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.
Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции.
Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая).
Здравствуйте, WolfHound, Вы писали:
_>>Угу, я уже понял что у вас в этом смысле всё круто. Правда только для одной IDE (от использования которой я отказался ещё несколько лет назад). А то я писал про вариант с DSL в обычных IDE. WH>Ох. Ещё раз. WH>Найтра на ИДЕ не завязана вообще от слова совсем. WH>Прямо сейчас есть интеграция в студию и отдельная WPF'ная программа с редактором в котором есть и подсветка и автодополнение и много чего ещё. WH>Точно так же найтру можно засунуть в любую другую программу.
В процессе нашего обсуждения Nemerle и т.п. я уже точно не первый раз повторяю фразу вида "можно сделать и можно скачать" — это очень разные вещи. Причём если говорить про всякие библиотеки и т.п., то там даже проще, т.к. хотя и надо впечатать код, но хотя бы только один раз. А в случае IDE это надо делать для каждой (а их сейчас десятки популярных, нет ни одного однозначного лидера) и в каждом случае по разному. Так что пока я всё же останусь при своём мнение, что реализация есть только под VS. Хотя понятно, что теоретически ситуация может измениться.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
Г>>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.
EP>Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции. EP>Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая).
Это неверно.
Скажем, тот код, который я привёл в прошлом сообщении, упадёт, будучи неверно написан, не «в одной из веток, до которой исполнение может быть и не доберётся, если не покрыть её тестами», а при любой загрузке всего кода. Иными словами, в языках без «стадии компиляции», всё равно есть несколько разных стадий существования кода; и DSL-и обычно определяются так, что контролируют правильность на ранних стадиях.
Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.
Здравствуйте, WolfHound, Вы писали:
_>>Так о том и речь. Причём этот DSL очевидно должен быть очень простой. А в тоже самое время первая команда могла параллельно использовать какой-нибудь мегасложный DSL на макросах, для статической проверки каких-то правил в своём коде. WH>Ох. В случае с найтрой это строго одно и то же. WH>Только набор макросов разный.
Ну ОК, посмотри тогда задачку ниже. )
_>>А кто мешается сделать так же с динамикой? ) У нас же это всё внутри одного приложения... WH>Удачи.
Что удачи? ) Вот я запускаю gcc на коде с ошибкой и он мне ругается "какая-то хрень в строке такой-то". Или я запускаю python с ошибочным скриптом и он точно так же ругается "какая-то хрень в строке такой-то". Где разница то для отображения ошибки в редакторе?
_>>Да, вот так отлично) Хотя понятно, что любители C# такое не воспримут и захотят только Linq вариант. ))) WH>Линк (особенно если это linq2db) объективно лучше.
с дальнейшими спорами на эту тему. ))) Но повторять то обсуждение я не вижу смысла, тем более, что непонятно о чём вообще можно спорить после таких http://rsdn.ru/forum/flame.comp/6013262
===============Небольшой оффтопик=================
Тут вот меня в разных вариантах приглашали внести свой вклад во всю эту тему (типа если критикуешь, то покажи как правильно на деле)... Но очевидно, что я не могу тратить существенно время на что-то вообще никак не пересекающееся с моими рабочими проектами. А вот если бы пересечение было, то почему бы и нет... Так вот у меня на самом деле есть задачка (хотя она вообще то уже решённая, но мне не нравится как и в будущем (после решения некоторых финансовых вопросов) я хотел бы изменить решение) очень близкая к вашей области. Вот мне интересно, что ты скажешь по её поводу...
Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог. Причём в своей полноценной реализации, в смысле возможностей работы с предикатами. А вот стандартная библиотека языка (ну там всякие writeln, open(file) и т.) вообще не нужна. Вместо неё должен быть набор разных предметных функций. А так же должна быть реализована возможность обработки событий, инициируемых в базовом языке. Ну и всё это должно работать быстро (soft realtime), многопоточно и с доступом к железу (из базового языка). Целевая ОС — Linux.
Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. )))
В данный момент задачка полностью решена в виде приложения на C++, которое использует готовый движок Пролога (написанный на C, совершенно адским кодом, который нереально изменять). Реализация не потребовала много времени и в принципе всё нормально работает, но итоговая архитектура мне не очень нравится (кривовато из-за особенностей реализации движка) и периодически вылезают разные острые углы. Если предположим в ближайшем будущем я захочу взять отдельного человека специально на решение задачи "избавиться от этого движка", то можешь ли ты предложить мне что-то интересное на базе ваших технологий? Или проще поставить задачу в виде "переписать как есть, только по-человечески"? )
Проблема редактора же полностью решена готовым компонентом QScintilla (100% кроссплатформенность, время интеграции в приложение — несколько часов). И я даже не знаю что ещё можно тут предложить для подобного DSL. Однако если у тебя есть какие-то идеи, то с удовольствием выслушаю.
==============================================
Здравствуйте, Гест, Вы писали:
_>>Так вот возвращаясь к динамике/статике. Моя основная мысль была в том, что на языке со статическим метапрограммированнием возможна реализация DSL как типа 1.Б (имеет смысл применять только если исполняемый "скрипт" запрашивается снаружи, а не зашит в приложение), так и типа 2.Б. А в языках с динамическим метапрограммированием в принципе возможен только тип 1.Б. Г>Мне кажется, что помимо (естественного для статики, но не базового для разработки вообще) деления на «проверяемое в компайлтайме» и «проверяемое в рантайме» нужно говорить о делении на проверяемое во время разработки и проверяемое в продакшене.
Я с этим абсолютно согласен. Только вот фокус в том, что разница заключается не только в проверке. Разница заключается в наличие/отсутствие в продакшене самого DSL, как сущности. Причём это не зависит от типа базового языка — скажем подредактировать строку с регулярным выражением можно и в скомпилированном C++ приложение.
Понятно, что чаще всего этот вопрос сводят к тестированию (конечно, самое актуальное для разработки). Но надо всегда понимать, что это всего лишь одно из следствий более фундаментальной разницы, а совсем не базовая вещь.
Кстати, актуальные для разработки следствия могут быть и совсем другие. К примеру в вопросах защиты ПО или вообще нераскрытия алгоритмов.
Г>И польза от идеи DSL в принципе — в том, что у нас получается лаконичный код, отражающий предметную область и надёжно проверяемый во время разработки (несмотря на то, что по классификации с точки зрения статики, всё это попадает в одну и ту же «самую неуважаемую» категорию). Пример (часть примера выше): Г>
Г>Чем интересна отмеченная строка? Г>* она сгенерирует некоторое количество кода (методы типа User.add_post, User.remove_post, User.posts.count и т.д.), который скорее всего корректен и оптимален; без этого пришлось бы реализовывать их все вручную и тестировать каждый в отдельности Г>* она — часть основного языка, и если ты напишешь has many :posts или has_much :posts или has_many posts — тебя поправит конечно не компилятор, но интерпретатор на этапе разработки Г>* она даёт раннее обнаружение ошибок: например, если таблицы posts не существует в БД или в ней нет ключа для ассоциации — код упадёт сразу при запуске с понятной и читаемой ошибкой (а не в одном из методов в рантайме, в котором ты опечатался в названии таблицы, хотя во всех остальных методах всё верно)
Нуу на самом деле я не уверен, что конкретно этот пример стоит называть именно DSL'ем. Потому что от языка всё же ожидается наличие какой-то внутренней нетривиальной логики. А это скорее похоже на просто библиотечную функцию с метапрограммированием. Разве что это только малая часть целого комплекса функций с неким общим контекстом? Ну и да, я никогда не говорил, что от динамического метапрограммирования вообще нет пользы.
Г>И всё это исключительно для демонстрации мысли, которую я написал как примечание к исходному посту (в целом верному): что плавающая грань между «этапом разработки» и «этапом исполнения» в динамических языках способствует более естественному проникновению идеи DSL в эту среду.
В принципе согласен. Если в варианте 1.A. базовый язык приложения оказывается совпадающим с выбранным для основы DSL'а скриптовым языком, то мы автоматически получаем бесшовную интеграцию, а сам DSL по сути сводится к написанию некой библиотеки на базовом языке.
Здравствуйте, Гест, Вы писали:
EP>>Даже при 100% покрытии строчек кода тестами, нет гарантии отсутствия ошибок которые могли бы быть отловлены в статически типизированных языках во время компиляции. EP>>Чтобы такую гарантию получить в динамически типизированных языках — нужно делать тесты на все комбинации возможных ветвей исполнения, что во-первых практически нереально, а во-вторых даже доказательство того что покрыты все комбинации ветвей — сама по себе нетривиальная задача (и по-всей видимости неразрешимая). Г>Это неверно.
Это верно для общего случая.
Г>Скажем, тот код, который я привёл в прошлом сообщении, упадёт, будучи неверно написан, не «в одной из веток, до которой исполнение может быть и не доберётся, если не покрыть её тестами», а при любой загрузке всего кода.
Примитивные случаи — да, может отловить первый попавшийся тест. А в общем случае даже 100% покрытие по строчкам кода не поможет.
Г>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется.
Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят".
Здравствуйте, alex_public, Вы писали:
_>Что удачи? ) Вот я запускаю gcc на коде с ошибкой и он мне ругается "какая-то хрень в строке такой-то". Или я запускаю python с ошибочным скриптом и он точно так же ругается "какая-то хрень в строке такой-то". Где разница то для отображения ошибки в редакторе?
Нормальные ИДЕ показывают, где ошибка без запуска. И даже без компиляции. Прямо во время набора кода.
_>Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог.
Кому должен?
_>Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. )))
Прямо сейчас найтра такое не может.
Но после того как мы полностью перепишем найтру на найтре и сделаем нативный бэкенд то не вопрос.
Просто в данный момент заниматься поддержкой нескольких бэкендов не рационально.
_>Если предположим в ближайшем будущем
Это зависит от того насколько оно ближайшее.
_>я захочу взять отдельного человека специально на решение задачи "избавиться от этого движка", то можешь ли ты предложить мне что-то интересное на базе ваших технологий? Или проще поставить задачу в виде "переписать как есть, только по-человечески"? )
На данный момент найтра для продакшена не пригодна.
_>Проблема редактора же полностью решена готовым компонентом QScintilla (100% кроссплатформенность, время интеграции в приложение — несколько часов). И я даже не знаю что ещё можно тут предложить для подобного DSL. Однако если у тебя есть какие-то идеи, то с удовольствием выслушаю.
QScintilla и близко не ИДЕ. Просто блокнот с подсветкой синтаксиса.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Нормальные ИДЕ показывают, где ошибка без запуска. И даже без компиляции. Прямо во время набора кода.
Ааа, всё, понял о чём ты. Ну кстати говоря такое и с динамикой будет частично работать (в том что касается синтаксиса языка). Хотя конечно более ограниченно, чем со статикой.
_>>Значит мне требуется DSL, который будет работать у пользователей. К счастью изобретать новый язык не требуется — это должен быть Пролог. WH>Кому должен?
Предметной области. ) А с чего вообще такие вопросы? )
_>>Кроме этого требуется ещё редактор с подсветкой для этого DSL. Целевые ОС: минимально Windows и Android, а в идеале все возможные. ))) WH>Прямо сейчас найтра такое не может. WH>Но после того как мы полностью перепишем найтру на найтре и сделаем нативный бэкенд то не вопрос.
Вообще то главная проблема как раз в самом dsl, а не в гуи редакторе к нему. ) Редактор — это так, мелочи.
WH>Просто в данный момент заниматься поддержкой нескольких бэкендов не рационально.
Я как раз и намекал, что в случае понимания реальной пользы для своих дел мог бы сам (лично или нет — не важно) вложиться в общую работу. )
_>>Если предположим в ближайшем будущем WH>Это зависит от того насколько оно ближайшее.
Скажем через полгодика. Ну плюс минус пара месяцев. )
_>>я захочу взять отдельного человека специально на решение задачи "избавиться от этого движка", то можешь ли ты предложить мне что-то интересное на базе ваших технологий? Или проще поставить задачу в виде "переписать как есть, только по-человечески"? ) WH>На данный момент найтра для продакшена не пригодна.
Да я же не про конкретный продукт, а вообще говорю. ) Что ты вообще можешь сказать про мой вопрос, взглянув так сказать со своей колокольни? )
WH>QScintilla и близко не ИДЕ. Просто блокнот с подсветкой синтаксиса.
Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения...
Г>>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется. EP>Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят".
Тесты все не отловят и на статике тоже. Тебе напомнить тривиальнейший пример, который «статисты» так и не смогли решить за два месяца? То-то же. Не надо преувеличивать и превозносить возможности и умения стат. типизации.
В этом топике лучше сосредоточится не на статика vs. динамика, имхо, а на обсуждении DSLей
Здравствуйте, Mamut, Вы писали:
Г>>>Впрочем, для нового витка вечного флейма «статика vs динамика» я что-то староват уже, кажется. EP>>Не надо флейма, главное не опускать существенные детали — мол "тесты всё отловят". M>Тесты все не отловят и на статике тоже.
Естественно, тесты и там всё не отловят.
А вот те ограничения которые задаются системой типов — проверяются гарантированно во время компиляции (если специально не обходить эту систему типов). Например так может проверятся правильность выражений на EDSL.
M>Тебе напомнить тривиальнейший пример, который «статисты» так и не смогли решить за два месяца? То-то же. Не надо преувеличивать и превозносить возможности и умения стат. типизации.
Не надо демагогии Я говорю про вполне конкретный аспект проверки правильности построения выражений DSL'ей во время компиляции.
Здравствуйте, alex_public, Вы писали:
_>Ааа, всё, понял о чём ты. Ну кстати говоря такое и с динамикой будет частично работать (в том что касается синтаксиса языка). Хотя конечно более ограниченно, чем со статикой.
Не думаю что ограничено тут правильное слово.
Там всё гораздо хуже.
Автокомплит комплитит, что не должен. Рефакоторинг переименования переименовывает, что попало итп.
_>Предметной области. ) А с чего вообще такие вопросы? )
Просто обычно такого счастья не бывает, что предметная область сводиться к готовому языку.
_>Вообще то главная проблема как раз в самом dsl, а не в гуи редакторе к нему. ) Редактор — это так, мелочи.
Найтра на данном этапе развития намертво прибита к .НЕТ
При помощи найтры, можно сгенерировать какой угодно код без привязки к платформе.
Но сам компилятор найтры ещё долго будет прибит гвоздями к .НЕТ.
А ведь тебе же компилятор в приложение встроить надо.
_>Я как раз и намекал, что в случае понимания реальной пользы для своих дел мог бы сам (лично или нет — не важно) вложиться в общую работу. )
Мы конечно рады любой помощи.
Но оторвать найтру от .НЕТ без полного бутстрапа не реально.
Ты, конечно, можешь попробовать, но потратишь уйму сил и скорее всего не осилишь.
Но даже если у тебя что-то получиться после бутстрапа оно всё равно пойдет в помойку.
Короче нужно соблюдать правильную последовательность развития. Иначе будет мучительно больно.
_>Да я же не про конкретный продукт, а вообще говорю. ) Что ты вообще можешь сказать про мой вопрос, взглянув так сказать со своей колокольни? )
Не понял, что конкретно ты хочешь от меня услышать.
Вопрос был про наши технологии. Наши технологии на данном этапе тебе не помогут.
_>Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения...
Подсветка там заканчивается на лексере.
А откуда оно возьмёт автодополнение вообще не ясно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Просто обычно такого счастья не бывает, что предметная область сводиться к готовому языку.
1. В данном случае не совсем готовому — я же описал какие пришлось сделать изменения.
2. Ну просто не плохо легли потребности на базовые возможности языка.
WH>Найтра на данном этапе развития намертво прибита к .НЕТ WH>При помощи найтры, можно сгенерировать какой угодно код без привязки к платформе. WH>Но сам компилятор найтры ещё долго будет прибит гвоздями к .НЕТ. WH>А ведь тебе же компилятор в приложение встроить надо.
Да, но у меня больше сомнения даже не из-за .net'a. Всё же его некое подобие есть под linux (ну а т.к. нам тут не нужен ни gui, ни другой системный api, то наверное даже всё работало бы). А вопросы быстродействия и доступа к железу вполне решаемы через взаимодействующий C++ код. Дело в другом — чего будет стоить разработка подобного движка с помощью ваших технологий? Мне вот совершенно не очевидно, как будет создаваться код, реализующий базовые возможности языка (а там всё не просто, одна унификация с откатами и отсечениями чего стоит, не говоря уже о динамической модификации базы предикатов). Т.е. в случае Пролога парсер языка — это как раз простейшая вещь, в отличие от реализации его рантайма... Ну и соответственно, если тут нет какой-то существенной помощи (обещали же "лёгкое создания DSL'ей"? ), то тогда проще написать реализацию в лоб на C++ — будет быстрее и эффективнее.
Кстати, а у вас вообще есть хоть один законченный пример готового DSL'я (вообще любого), отрабатывающего во время исполнения приложения, а не во время компиляции?
_>>Конечно. Но мне именно блокнот (точнее там на самом деле речь о неком большом и сложном приложение, а это всего лишь его модуль) и нужен. Другое дело, что можно обсуждать уровень качества подсветки и автодополнения... WH>Подсветка там заканчивается на лексере. WH>А откуда оно возьмёт автодополнение вообще не ясно.
Как-то так: http://habrahabr.ru/post/144855/. Ну и с подсветкой аналогично, можно сделать умную. Но для нашего случая хватит и обычной.
M>>Тебе напомнить тривиальнейший пример, который «статисты» так и не смогли решить за два месяца? То-то же. Не надо преувеличивать и превозносить возможности и умения стат. типизации.
EP>Не надо демагогии Я говорю про вполне конкретный аспект проверки правильности построения выражений DSL'ей во время компиляции.
Здравствуйте, alex_public, Вы писали:
_>И так DSL. На мой взгляд вся эта область делится на две принципиально разных части: dsl исполняемые в процессе разработки ПО и dsl исполняемые в процессе работы ПО. Рассмотрим по отдельности.
Касательно DSL в процессе разработки: в крупной индустрии ниша DSL-я забита UML-ем в разных вариациях с кодом внутри моделей на Java/C/C++/etc.
Ну и динамические языки само собой. Никто не будет городить новый DSL для какой-то задачи. Возьмут существующие решения. Да и .NET-у тут не место.
Здравствуйте, sergey179, Вы писали:
S>Касательно DSL в процессе разработки: в крупной индустрии ниша DSL-я забита UML-ем в разных вариациях с кодом внутри моделей на Java/C/C++/etc. S>Ну и динамические языки само собой. Никто не будет городить новый DSL для какой-то задачи. Возьмут существующие решения. Да и .NET-у тут не место.
А для этого используются какие-то готовые известные инструменты или речь про свои внутренние? ) Я вот с UML вполне себе работаю, но кодогенерацию никогда не использовал в реальных проектах.
Здравствуйте, alex_public, Вы писали:
_>А для этого используются какие-то готовые известные инструменты или речь про свои внутренние? ) Я вот с UML вполне себе работаю, но кодогенерацию никогда не использовал в реальных проектах.
Речь о крупном бизнесе: Ericsson, Raytheon, Aetna, Lockhead Martin Corp, British Telecom и т.п. Они используют. Продукты разные, есть большая пачка наших, IBM-их продуктов, есть сторонние производители. В большинстве случаев готовые тулы расширяются customer-specific плагинами для конкретной ситуации.
Тот же Эриксон генерит код (гигабайты) который непосредственно идет в девайсы. Не технические компании обычно генерят web-service-ы (WSDL/XSD/Java) , BPEL и т.п
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, WolfHound, Вы писали:
_>>>Разница принципиальна. Одно — это инструмент создания приложения, а другое — это инструмент кастомизации готового приложения. WH>>Как по мне так это одно и то же.
_>Для начала, этим могут заниматься разные люди с очень разным уровнем подготовки.
Не могу пройти мимо этого аргумента. По сути он неявно предполагает:
1) необходимость предоставления пользователю ПО максимально удобного инструментария
2) достаточность предоставления квалифицированному программисту минимально необходимого инструментария
Так быть не должно. При решении нетривиальной задачи интересно задуматься — каким инструментарием я хотел бы обладать, чтобы решить эту задачу очевидно корректным и максимально удобным способом? Если ответ на этот вопрос найден (что часто совсем непросто), то задача сводится к "всего лишь"
Step1) созданию инструментария
Step2) тривиальному созданию решения на основе этого инструментария
Что делает решение (работу пользователя) тривиальной?
используется терминология из предметной области
максимальная выразительность языка — можно быстро и с уверенностью проверить корректность решения (форма может сильно варьироваться, от текстовой до графической)
простота — знакомства с предметной областью должно быть достаточно
пользователи должны иметь возможность проверять свои идеи в реальном времени (записали — протестировали, никаких долгих стадий компиляции, перезапуска, т.п.)
очевидность и своевременность обратной связи в случае ошибок
эргономичность используемого ПО
Именно так, все в кучу, без приоритетов, неразрывно смешав простоту работы с простотой результата (кода, диаграммы, данных, чего бы то ни было). Создавая dsl, мы должны думать о нем как о продукте, у которого есть свой пользователь. Мы должны представить себя на месте этого пользователя и почувствовать счастье от обладания подобным инструментом.
Именно поэтому мне очень нравится идеи, стоящие за Nitra — это четкое понимание того, что никому не нужен просто очередной парсер, что dsl — это не грамматика, а продукт, предназначенный для конечного пользователя. Это программирование будущего.
В настоящем же мы по многим причинам часто встречаем перекос — мы жертвуем простотой Step2 (см. выше) в угоду упрощения Step1:
> В большинстве случаев наиболее логичным и эффективным способом является встраивание какого-то из интерпретируемых языков общего назначения, с добавлением набора специфических для предметной области функций. Чаще всего это Lua, Python, JavaScript...
Ведь главное чтобы пользователь/программист мог решить задачу, не так ли? Не так. DSL должен быть таким, чтобы задачу нельзя было не решить.
Я говорю про вполне конкретный аспект проверки правильности построения выражений DSL'ей во время компиляции.
