DSL Q&A

2008年9月9日

ドメイン特化言語

非技術者向けにDSLに関する議論をまとめるよう依頼されました。Stephen O'Gradyの文章を読みすぎているのかもしれませんが、どうしてもQ&A形式で書きたくなってしまいました。それでは始めましょう。

ドメイン特化言語とは何ですか？

ドメイン特化言語（DSL）とは、特定のドメインに焦点を当てた表現力の限定されたコンピュータプログラミング言語です。一般的に知られている言語のほとんどは汎用言語であり、ソフトウェアプロジェクトで遭遇するほとんどの状況に対応できます。各DSLは、システムの特定の側面しか処理できません。

つまり、DSLだけでプロジェクト全体を作成することはできませんか？

いいえ。ほとんどのプロジェクトでは、1つの汎用言語と複数のDSLを使用します。

新しいアイデアですか？

全く新しいものではありません。DSLは、Unixシステムの初期からUnix界隈で広く使用されてきました。Lispコミュニティでは、LispでDSLを作成し、そのDSLを使用してロジックを実装することがよく話題になっています。ほとんどのITプロジェクトでは複数のDSLを使用しています。CSS、SQL、正規表現などがその例です。

では、なぜ今注目されているのでしょうか？

おそらくRubyとRailsのおかげでしょう。RubyはDSLの開発を容易にする多くの機能を備えており、Rubyコミュニティに関わってきた人々は他の場所からこのアプローチに精通していたため、これらの機能を利用しました。特にRailsは複数のDSLを使用しており、それがRailsの使いやすさに大きく貢献しています。これはさらに多くの人々がこれらのアイデアを採用するきっかけとなりました。

もう一つの理由は、多くのJavaやC#システムでは、動作の一部をより動的な方法で定義する必要があることです。これにより、理解が難しい複雑なXMLファイルが生成され、結果として人々は再びDSLを探求するようになりました。

DSLはRuby以外の言語でも使用できますか？

はい、述べたようにDSLはRubyよりもずっと前から存在しています。Rubyは、C#やJavaのような言語よりも洗練された内部DSLを作成しやすい、控えめな構文とメタプログラミング機能を備えています。しかし、JavaやC#にも有用な内部DSLは存在します。

内部DSLと外部DSLの違いは何ですか？

内部DSLとは、ホスト言語でコードを書く特定のイディオムです。つまり、Ruby内部DSLはRubyコードであり、特定のスタイルで記述することで、より言語らしい感覚を与えます。そのため、Fluent Interfaces（流暢なインターフェース）または埋め込みDSLと呼ばれることもあります。外部DSLは、ホスト言語が理解できるデータに解析される完全に独立した言語です。

人々がDSLに関心を持つのはなぜですか？

DSLには2つの主な利点があると私は考えています。最も一般的な利点は、特定の種類のコードの理解を容易にすることで、修正が容易になり、プログラマーの生産性が向上することです。これはそれ自体で価値があり、比較的簡単に実現できます。

しかし、最も興味深い利点は、適切に設計されたDSLであればビジネス担当者も理解できるようになり、ビジネスルールを実装するコードを直接理解できるようになることです。

つまり、ビジネス担当者が自らルールを作成できるようになるのが最大のメリットですか？

一般的に、そうは思いません。ビジネス担当者が独自のルールを作成できる環境を作るには多くの作業が必要です。快適な編集ツール、デバッグツール、テストツールなどを用意する必要があります。ビジネス向けのDSLの利点の大部分は、ビジネス担当者がルールを読めるようにするだけで得られます。ビジネス担当者は、正確性を確認したり、開発者と話し合ったり、開発者が適切に実装するための変更案を作成したりすることができます。DSLをビジネス向けに可読にするには、ビジネス向けに記述可能にするよりもはるかに少ない労力で済みますが、ほとんどの利点が得られます。DSLをビジネス向けに記述可能にする努力をする価値がある場合もありますが、より高度な目標です。

特別な（つまり高価な）ツールが必要ですか？

一般的には、いいえ。内部DSLは、使用しているプログラミング言語の通常の機能を使用するだけです。外部DSLでは、いくつかの特別なツールを使用する必要がありますが、これらはオープンソースであり、非常に成熟しています。これらのツールに関する最大の課題は、ほとんどの開発者がそれらに精通しておらず、実際よりも使いにくいと考えていることです（これは、ドキュメントの不足によってさらに悪化します）。

ただし、地平線には例外があります。LanguageWorkbenchと私が呼ぶツールのクラスです。これらのツールを使用すると、DSLをより簡単に定義でき、高度なエディターも提供されます。このようなツールにより、ビジネス向けに記述可能なDSLを作成することがより現実的になります。

これは、プログラミング（またはプログラマー）なしでソフトウェアを開発するという夢の繰り返しですか？

それはCOBOLの意図であり、DSLがCOBOL（そして多くの他の失敗例）で失敗した場所で成功すると考える理由はありません。私が重要だと思うのは、DSLによってビジネス担当者と開発者がより効果的に連携できるようになることです。なぜなら、実行可能なコードである共通の一連の正確なルールについて話し合うことができるからです。

いつDSLの作成を検討すべきですか？

豊富なビジネスルールまたはワークフローを持つシステムの側面を検討している場合です。適切に記述されたDSLは、顧客がシステムの動作ルールを理解できるようにする必要があります。

これは、人々が学習に苦労する言語の騒音につながりませんか？

プログラマーが学習しなければならないフレームワークの騒音はすでにあります。それは再利用可能なソフトウェアの必然的な結果であり、今日のソフトウェアが実行しなければならないすべてのことを把握する唯一の方法です。本質的に、DSLはフレームワークの上の飾り気のないファサードにすぎません。その結果、既に存在するものに比べて複雑さをほとんど加えません。実際、優れたDSLは、これらのフレームワークを使いやすくすることで、状況を改善するはずです。

しかし、人々は多くの悪いDSLを作成しませんか？

もちろん、人々は悪いフレームワークを作成するのと同じようにです。しかし、繰り返しになりますが、悪いDSLは、悪いフレームワークのコストと比較して、追加の害をほとんど及ぼさないと思います。