Когда мне следует использовать язык, специфичный для предметной области? [закрыто]

Question

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

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

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

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

Answer 1

Очень мало веских причин для создания еще одного DSL. Мир полон языков специального назначения.

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

<Ол>

Решите проблему с помощью языка общего назначения, такого как Python, Java, C ++ и т. д.

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

Оптимизируйте эту библиотеку классов, чтобы подчеркнуть "ортогональность". Убедитесь, что все функции работают хорошо вместе, без каких-либо проблем.

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

Если вам все еще нужна дополнительная оптимизация, подумайте над написанием компилятора для вашего DSL.

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

Answer 6

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

Если вам нужно создать свой собственный, я бы сказал, что для поиска доменов нужно приложить немало усилий, чтобы просто правильно указать вещи, и где ваш компилятор не сможет найти большинство ошибок, но компилятор, зависящий от домена, может , Графические интерфейсы являются отличным примером, поскольку большая часть работы заключается в настройке макета, и, как правило, существует множество способов сделать синтаксически допустимые вызовы C ++, которые не имеют никакого смысла для вашей базовой системы графического интерфейса (например, попытка встроить весь диалог виджет внутри кнопки).

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