Когда я должен использовать определенный для домена язык?

Я хотел бы получить некоторое практическое руководство, когда я должен использовать Специфичный для домена язык. Я нашел ресурсы о преимуществах и недостатках, но какой проект мог бы гарантировать его использование?

Кажется, что есть большие инвестиции вовремя, чтобы создавать и поддерживать DSL, поэтому в каком пространстве приложения я получаю доход от производительности при моем инвестировании времени?

Изменить:. Кажется, что наиболее распространенное использование DSL для форматов файлов для сохранения состояния данных, а также использования DSL для логики и структуры программы (возможно, для генерации кода)? Когда это возможно?

Изменить # 2 Я в основном задаю вопрос о том, когда стоит создать конкретный DSL. Конечно, мы должны использовать существующие DSL как можно больше, чтобы сэкономить время.

Ответ 1

Существует очень мало веских причин для создания еще одного DSL. В мире жир со специальными языками.

Подумайте вместе с этими строками.

Решите проблему с языком общего назначения, таким как Python, Java, С++.. что угодно.
Оптимизируйте это решение, чтобы разделить общие функции и создать действительно красивую, действительно элегантную, действительно расширяемую библиотеку классов.
Оптимизируйте эту библиотеку классов, чтобы подчеркнуть "ортогональность". Убедитесь, что все функции хорошо работают вместе, без каких-либо проблем.
Если вам требуется упрощение только синтаксиса, создайте оболочку сценариев вокруг вашей классной библиотеки классов. Это ваш DSL. Для Python это легко - это уже динамический язык. Для Java есть вещи, которые вы можете использовать. Для С++ это может быть немного трудным для создания этой гибкой среды сценариев.
Если вам все еще нужна дополнительная оптимизация, подумайте о написании компилятора для своего DSL.

Ответ 2

Статья ACM Computing Surveys Когда и как разрабатывать языки, специфичные для домена, дается совет по этой теме, как и книга Мартина Фаулера 2010 года Языки домена.

Ответ 3

Во-первых, я бы использовал DSL, когда проблемный домен, с которым вы развиваетесь, является широко известным доменом, а некоторые бизнес-эксперты этого домена уже прошли большую работу по созданию такой DSL что вам не придется проходить через себя самостоятельно, чтобы решить все проблемы, которые они уже выяснили.

Если вы думаете о создании DSL, я бы подумал о том, чтобы сделать это, если ваш бизнес выполняется в очень конкретной области, и вы тратите большую часть своего времени на фокусирование в определенном проблемном домене, Если вы откажитесь от приложений для нескольких проблемных областей, я бы не советовал принять этот подход.

Например, если ваша компания работает в создании налоговых приложений, может быть хорошей идеей построить DSL налоговой системы. Это позволило бы использовать ваш язык не только для использования в ваших различных налоговых приложениях, но и для других компаний в вашей отрасли, которые могут быть доступны для продажи (которые можно использовать), которые хотят выполнять аналогичные действия, которые вы выполняете.

Конечно, вам нужно весить затраты/выгоды от создания DSL и рамки поверх уже существующего языка.

Ответ 4

Одна ситуация, которая приходит на ум, - это когда требования требуют очень высокого или невероятного уровня настройки/конфигурации. Таким образом, вы бы предложили своего рода модель сценариев вместо DSL.

Возьмем, например, "сборку" автомобиля, чтобы обеспечить конфигурационную модель для поддержки различных конфигураций factory. (обнаружите это, не обнаруживайте, что, когда это произойдет, сделайте это... и т.д.)

Но компиляция нового приложения со специализированной логикой для каждого клиента, вероятно, не является хорошим способом. Таким образом, в этом случае вы создаете небольшую структуру, которая станет своего рода DSL, а затем для каждой продаваемой вами роботизированной руки вы пишете небольшое приложение в своей DSL и сохраните его вместе с основным программным обеспечением, которое будет компилировать и запускать DSL вместо скриптов. Или еще лучше, инструменты для программирования DSL включены вместе с роботизированной ручкой, чтобы ваш клиент мог "запрограммировать" руку в созданном DSL.

Один реальный пример, который приходит на ум, - это Yahoo Pipes (вы можете думать о нем как DSL) или директив robots.txt для автоматизированного веб-искателя, например. Они не могут быть полноразмерными DSL, но они показывают, где DSL может быть полезен.

Ответ 5

Ну, кто-то должен это сказать, так вот:

Lisp рассматривается некоторыми как язык, специфичный для домена для любой области. Хорошо поддерживаемый и очень расширяемый DSL.

В некоторых случаях создание DSL из Lisp (или аналогичного языка, такого как Haskell) могло бы фактически обеспечить большую мощность с минимальными усилиями, и, следовательно, было бы весьма полезно. DSL не всегда должны быть большим бременем обслуживания.

Ответ 6

Наиболее очевидным является то, что вы обязательно должны использовать их, когда язык уже существует и хорошо поддерживается. Главными примерами этого являются UIL для разработки графического интерфейса на основе Motif и разработка программных сборок.

Если вам нужно сделать свой собственный, я бы сказал, что поиск доменов требует больших усилий, чтобы просто правильно определить вещи и где ваш компилятор не может найти большинство ошибок, но компилятор, специфичный для домена, может, GUI - отличный пример, так как большая часть работы заключается в настройке макета, и, как правило, существует множество способов сделать синтаксически допустимые вызовы С++, которые не имеют никакого отношения к вашей базовой системе графического интерфейса (EG: попытка встроить весь диалог виджет внутри кнопки).

Я нахожу, что UIL особенно полезен для разработки GUI, потому что компилятор UIL может найти ошибки в спецификации GUI, которые просто похожи на хороший обычный компилируемый код на компилятор С++. Тот факт, что он хорошо поддерживается, означает, что код легко переносится между платформами и даже разработчиками графического интерфейса.