Вопрос по project-management, dsl – Когда мне следует использовать язык, специфичный для предметной области?

29

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

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

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

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

& quot; ... мы должны максимально использовать существующие DSL для экономии времени. & quot; Я не думаю, что это правда. Andreas

Ваш Ответ

6   ответов
15

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

Думайте вместе с этими линиями.

  1. Solve the problem with a general-purpose language such as Python, Java, C++.. whatever.

  2. Optimize that solution to factor out the common features and build a really nice, really elegant, really extensible class library.

  3. Optimize that class library to emphasize "orthogonality". Make sure all features work well together, without any problems.

  4. If you need simplification of the syntax only, create a scripting wrapper around your nice class library. This is your DSL. For Python, this is easy -- it's already a dynamic language. For Java, there are things you can leverage. For C++ it can be a bit of work to build this flexible scripting environment.

  5. If you still need further optimization, consider writing a compiler for your DSL.

Что такое хороший ресурс для изучения того, как разрабатывать предметно-ориентированные языки?
3

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

Лисп рассматривается некоторыми как предметно-ориентированный язык дляany домен. Хорошо поддерживаемый и очень расширяемый DSL.

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

Возможно, то же самое или наоборот: я думаю, что ООП - это попытка получить GPL для определения DSL (классов), которые распознаются компилятором GPL. Другие ответы утверждают, что это невозможно, или неправдоподобно, или просто глупо, что я согласен. GPL создает инструменты, которые манипулируют DSL. Никогда два уровня не должны встречаться. Таким образом, GPL все еще может быть простым, как C. OOP - это глупое сочетание косвенности и безрассудного злоупотребления выразительностью. Гм.
3

One situation that comes to mind is when the requirements requires a very high or improbable level of customization/configuration, Таким образом, вместо этого вы предоставите своего рода модель сценариев для DSL.

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

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

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

12

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

Похоже, очень тщательное рассмотрение вопроса, спасибо! Kekoa
2

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

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

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

11

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

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

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

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

Спасибо за указание на различие. DSL действительно окружают нас, я полагаю, я спрашиваю больше о создании DSL. Kekoa
Это в основном повторяет мой ответ. Моя политика, когда это происходит, заключается в том, что вы явно гений. Upvote! :-)

Похожие вопросы