どのような場合にドメイン固有言語を使用する必要があるかについて、実用的なガイダンスが欲しいです。長所と短所に関するリソースを見つけましたが、どのような種類のプロジェクトでその使用が正当化されますか?
DSL の作成と保守には多大な時間が費やされているように思われますが、時間の投資に対して生産性が得られるのはどのアプリケーション領域でしょうか?
編集: DSL の最も一般的な用途は、データ状態を永続化するためのファイル形式のようですが、プログラムのロジックと構造 (おそらくコード生成) に DSL を使用するのはどうですか? これはいつ実現可能ですか？
編集 #2私は主に、特定の DSL をいつ作成する価値があるかについて質問しています。もちろん、時間を節約するために、可能な限り既存の DSL を使用する必要があります。
さらに別のDSLを作成する正当な理由はほとんどありません。世界は特別な目的の言語で太っています。
これらの線に沿って考えてください。
Python、Java、C++などの汎用言語で問題を解決します。
そのソリューションを最適化して、共通の機能を除外し、非常に優れた、非常にエレガントで、非常に拡張可能なクラスライブラリを構築します。
そのクラスライブラリを最適化して、「直交性」を強調します。すべての機能が問題なく連携して機能することを確認してください。
構文の簡略化のみが必要な場合は、素敵なクラスライブラリの周りにスクリプトラッパーを作成してください。これはあなたのDSLです。Pythonの場合、これは簡単です。すでに動的言語です。Javaの場合、活用できることがあります。C ++の場合、この柔軟なスクリプト環境を構築するのは少し手間がかかる場合があります。
さらに最適化が必要な場合は、DSL用のコンパイラを作成することを検討してください。
ACM Computing Surveys の記事When and How to Develop Domain-Specific Languagesは、Martin Fowler の 2010 年の書籍Domain-Specific Languagesと同様に、このトピックに関するアドバイスを提供しています。
まず、開発対象の問題のあるドメインが広く知られているドメインである場合、DSLを使用します。そのドメインの一部のビジネス専門家は、このようなDSLを構築するためにすでにかなりの時間を費やしているため、彼らがすでに理解しているすべての問題を解決するために自分自身を長引かせます。
DSLの作成を考えている場合、ビジネスが非常に特定の領域で行われ、時間の大部分を特定の問題領域に集中する場合は、DSLの作成を検討します。複数の問題のあるドメインのアプリケーションを実行することにバウンスする場合は、そのアプローチを取ることはお勧めしません。
たとえば、あなたのビジネスが税務アプリケーションの構築に苦労している場合は、税務システムDSLを構築することをお勧めします。これにより、あなたの言語はさまざまな税務申請で使用できるだけでなく、あなたが達成しているのと同様のことをしたい業界の他の企業でも市場に出せる（使用できる）ようになります。
もちろん、既存の言語に加えて、DSLとフレームワークを構築するコスト/メリットを比較検討する必要があります。
頭に浮かぶ状況の1つは、要件が非常に高いレベルまたはありそうもないレベルのカスタマイズ/構成を必要とする場合です。したがって、代わりにDSLに対して一種のスクリプトモデルを提供します。
たとえば、自動車アセンブリの「アーム」を例にとると、さまざまな工場構成をサポートする構成モデルを提供することは不可能です。（これを検出し、検出しないでください。これが発生した場合は、これを実行してください...など）
しかし、顧客ごとに専用のロジックを使用して新しいアプリケーションをコンパイルすることは、おそらく良い方法ではありません。したがって、この場合、一種のDSLになる小さなフレームワークを作成し、販売するロボットアームごとに、DSLに小さなアプリを作成し、DSLをコンパイルして実行するコアソフトウェアと一緒に保存します。代わりにスクリプト。さらに良いことに、DSLをプログラムするためのツールがロボットアームとともに含まれているため、顧客は作成したDSLでアームを自分で「プログラム」できます。
頭に浮かぶ実例の1つは、Yahoo Pipes（DSLと考えることができます）や自動Webクローラー用のrobots.txtディレクティブです。それらは本格的なDSLではないかもしれませんが、DSLがどこで役立つかを示しています。
まあ、誰かがそれを言わなければならないので、ここに行きます：
Lisp は、あらゆるドメインのドメイン固有言語と見なされている人もいます。その点で、十分にサポートされ、非常に拡張可能な DSL です。
場合によっては、Lisp (または Haskell などの同様の言語) から DSL を作成すると、実際には最小限の労力で多くの機能を提供できるため、非常に価値があります。DSL は、常に大きな保守負担である必要はありません。
最も明白なのは、言語がすでに存在し、十分にサポートされている場合は、必ずそれらを使用する必要があるということです。この代表的な例は、MotifベースのGUI開発用のUILとソフトウェアビルド用のmakeです。
自分で作成する必要がある場合は、ドメインを探すのに多大な労力が必要です。適切に指定するだけで、コンパイラはほとんどのエラーを見つけることができませんが、ドメイン固有のコンパイラは見つけることができます。GUIは優れた例です。ほとんどの作業はレイアウトの設定であり、構文的に有効なC ++呼び出しを行う方法は一般にたくさんありますが、基盤となるGUIシステムにはまったく意味がありません（例：ダイアログ全体を埋め込もうとする）ボタン内のウィジェット）。
UILコンパイラーは、C ++コンパイラーにとって通常のコンパイル可能なコードのように見えるGUI仕様のエラーを見つけることができるため、UILはGUI開発にとって特に大きなメリットがあると思います。十分にサポートされているという事実は、コードがプラットフォーム間、さらにはGUIビルダー間でも簡単に移植できることを意味します。