ソフトウェアロジックのほとんどは、プログラミング言語で記述されており、これらはそのようなロジックを記述および進化させるための最適な環境を提供します。しかし、命令型コードが解釈できるデータ構造にロジックを移行すると便利な場合があります。これは私が適応モデルと呼ぶものです。ここでは、JavaScriptで記述された製品選択ロジックを示し、JSONでエンコードされた簡単なプロダクションルールシステムにリファクタリングする方法を示します。このJSONデータを使用すると、異なるプログラミング言語を使用するデバイス間でこの選択ロジックを共有し、これらのデバイスのコードを更新せずにロジックを更新できます。

これは私が通常行うDSLの入門講演ですが、通常よりもDSLに詳しい聴衆に向けて話すため、少し趣向を凝らしています。つまり、私がどのように人々にDSLを紹介しているかについての講演に内容を修正しました。

マイクロソフトのチャンネル9による、私、同僚のNeal Ford、およびJeffery Snover（PowerShellの作成者）へのインタビューです。一般的なトピックはDSLについてです。Nealと私はJAOO 2008でこのトピックに関するチュートリアルを終えたばかりで、Jefferyといくつかの良い会話をしました。

私がDSL DevConに参加したとき、マイクロソフトのチャンネル9が私を捕まえ、Chris Sellsによるインタビューを受けました。

私がNeal Fordと行ったThe Server Side Java Symposiumでの基調講演です。ドメイン特化言語への動きの高まり、どのような種類の言語が存在し、なぜそれらが興味深いのかについて考察します。この主題に関する講演を1つ探している場合は、JAOOの動画が私の好みですが、この講演はいくつかのテーマを拡張しており、Nealの存在によりさらに面白いものになっています。オーディオストリームを抽出する方法が見つかれば、オーディオのみでも問題なく機能します。

DSLの本の貢献者であるThoughtworksのCTO、Rebecca Parsonsが加わり、Markus VölterとDSLについて話し合います。DSLとは何か、内部DSLと外部DSLの違い、およびDSLを使用すべき場合（および使用すべきでない場合）について話し合います。

DSLを使用すると、ビジネスパーソンはプログラマーを関与させずにソフトウェアルールを作成できるようになるでしょうか。

人々がDSLについて話すとき、ビジネスパーソンが自分でコードを書くという質問がよく提起されます。この考え方には、COBOLの推論を適用したいと思います。つまり、COBOLの本来の目的の1つは、プログラマーなしで人々がソフトウェアを書くことを可能にすることでしたが、それがどのようにうまくいったかはご存知のとおりです。したがって、プログラマーなしでコードを書くためのスキームが考案された場合、COBOL（および他の多くのもの）が失敗した場所で成功するために、今回は何が特別なのかを問う必要があります。

テクノロジーによってユーザーが独自のソフトウェアを記述でき、プログラマーが不要になると主張しているのをよく目にします。これを聞くと、COBOLの目的がそうであったことを思い出したいと思います。そして、その結果はご存知のとおりです。

技術系ではない人向けにDSLに関する議論をまとめるように依頼されました。おそらく、Stephen O'Gradyを読みすぎたのかもしれませんが、Q&A形式で書きたくてたまらなくなりました。ということで、どうぞ。

ドメイン特化言語（DSL）の基本的な考え方は、あらゆる種類のソフトウェア問題に対応するように設計された汎用言語ではなく、特定の種類の問題を対象としたコンピューター言語であるということです。ドメイン特化言語は、コンピューティングが行われてきたのとほぼ同じくらい長い間、議論され、使用されてきました。

ドメイン特化言語の話題が出てきたとき、よくある疑問の1つは、DSLとは何か、何がDSLではないのかということです。問題は、DSLに正確な定義がなく、DSLと他のものの間に大きなグレーゾーンがあるということです。

外部ドメイン特化言語について書く際に難しいことの1つは、プログラミング言語コミュニティによってすでに十分に追跡されている領域を歩いているということです。プログラミング言語の研究は常に学術活動の人気のある分野であり、私はこの分野で長年研究している多くの人々ほどこのトピックを深く理解していないことを最初に認めます。したがって、必然的に、なぜ私のような新参者がこの踏み慣らされた分野で本を書くことができると思うのかという疑問が出てきます。

DSLの提唱者が注意する必要がある危険性の1つは、最初にDSLを設計し、次に人々がそれを使用するという考え方です。他のソフトウェアと同様に、成功したDSLは進化します。これは、DSLの以前のバージョンで作成されたスクリプトが、後のバージョンで実行された場合に失敗する可能性があることを意味します。

ここ数週間、私はコンパイラーコンパイラツールを試したり、調べたりしています。これらのツールの一般的な機能は、言語の文法の生成規則を記述したものがコアとなる文法ファイルを持っているということです。このファイルは、文法を記述するだけでなく、パーサーに言語要素を認識するときに言語を処理する方法に関する情報も提供します。ほとんどのコンパイラーコンパイラツールでは、これらの指示は文法内のアクションとして表現されます。多くの場合、これらのアクションは高レベル言語のコードフラグメントとしてエンコードされます。

FluentInterfaceの問題点の1つは、いくつかの奇妙なメソッドになってしまうことです。この例を考えてみましょう。

私は外部DSL用のさまざまな代替言語と文法を調べています。このための私の主なツールの1つはAntlrです。この種の調査では、複数の類似した文法ファイルを持つプロジェクトがあり、そこで異なる文法で基本的に同じことを実行したいと考えています。現時点では数個の文法ファイルしかありませんが、最終的には数十個になる可能性があります。

数か月前、私はEric Evansとのワークショップに参加しましたが、彼は特定のスタイルのインターフェースについて話しました。私たちがそれをFluent Interfaceと名付けることにしました。それは一般的なスタイルではありませんが、もっと知っておくべきだと私たちは考えています。おそらく、それを説明する最良の方法は例を挙げることです。

Given-When-Thenは、テストを表現するスタイル、またはその提唱者が言うように、SpecificationByExampleを使用してシステムの動作を指定するスタイルです。これは、Daniel Terhorst-NorthとChris MattsがBehavior-Driven Development（BDD）の一部として開発したアプローチです。Cucumberなどの多くのテストフレームワークの構造化アプローチとして表示されます。また、4段階テストパターンの再構成と見なすこともできます。

数年前、当時の同僚であったMatt Foemmelは、ソフトウェアの構築に使用していたツールに不満を抱き、Charles Simonyiに連絡を取り、謎のIntentional Softwareについて詳しく知ることに成功しました。彼が見たものは彼を感銘させ、彼は私や他のThoughtWorkerも巻き込むように説得しました。私たちが見たものは驚くべき可能性を秘めたツールでしたが、秘密主義とリリースへの緊急性の欠如に不満を抱いたままでした。その不満は先週終わりました。

内部DSL（埋め込みDSLとも呼ばれます）は、既存のホスト言語内に記述されたドメイン特化言語です。これは、多くのプログラミング言語コミュニティ、特にLispコミュニティで一般的な考え方です。DSLが急速に成長しているRubyコミュニティで一般的な考え方であるため、現在多くの注目を集めています。

言語ワークベンチは、私が2005年に、複数の統合されたドメイン特化言語の豊富な環境を通じてソフトウェアを構築するように設計された、新しいクラスのソフトウェア開発ツールを説明するために作った用語です。これらのツールはまだ主流からはかなり遠いものですが、それらの開発は継続しており、引き続き興味深いものです。これらは、プログラミングの状況を大きく変える可能性のある数少ないものの1つだと感じています。

私が最近の言語ワークベンチに関する記事を書いたとき、新しいものが表示されたときに更新を報告しやすくするために、参考文献のセクションをblikiに分離することにしました。

私は、プログラマーとして考えていない人を意味する用語として素人プログラマーを使用しています。一日の大半をスプレッドシートで作業している人は、プログラミング、多くの場合非常に集中的なプログラミングを行っています。しかし、通常、彼女は自分をプログラマーと呼ぶことも、プログラミングをより良くする方法を学ぶために多くの時間を費やすことも考えていません。

モデル駆動型ソフトウェア開発 (MDSD) と ドメイン固有言語 (DSL) の間にはどのような関係があるのでしょうか？

MDSDの文脈で「DSL」という用語を目にすることは非常に一般的です。実際、一部のMDSD関係者は、DSLはMDSDの世界の中にのみ存在すると考えているようです。私は最近、自分の本のためにDSLについてたくさん書いていますが、今のところMDSDの観点にはあまり触れていません。代わりに、より従来のプログラミングにおけるDSLの役割に焦点を当ててきました。DSLはテキスト言語とMDSDの両方の世界に存在し、両方に対してほぼ同じ役割を果たしています。

セルゲイ・ドミトリエフ氏は、IntelliJ IdeaやReSharperのような素晴らしいツールを提供してくれたJetBrainsのリーダーの一人です。彼は最近、メタプログラミングシステムと呼ばれる実験的な開発に関する記事を発表しました。彼はこのシステムを、言語指向プログラミングと呼ぶ、より広範な動きの一例と捉えています。

モデル駆動型ソフトウェア開発 (MDSD) は、従来のプログラミングスタイルに代わるものとみなすソフトウェア開発スタイルです。このアプローチは、ソフトウェアシステムのモデルを構築することに重点を置いています。これらのモデルは通常、図式的な設計表記（UMLが一つの選択肢です）を通じて具体化されます。この考え方は、これらの図を使用してシステムをモデリングツールに指定し、次に従来のプログラミング言語でコードを生成するというものです。

オスロはマイクロソフトのプロジェクトであり、今週のPDCカンファレンスまで詳細がほとんど不明のまま、さまざまなことが耳に入ってきました。私たちが知っていたのは、それがモデル駆動型ソフトウェア開発とドメイン固有言語に関係しているということでした。

私は最近、ドメイン固有言語について人々とよく話しますが、外部DSLに対する一般的な反応は、パーサーを書くのが難しいということです。実際、外部DSLのキャリア構文としてXMLを使用する正当化の一つは、「パーサーを無料で入手できる」ということです。これは私の経験とは一致しません。私はパーサーはほとんどの人が思っているよりもずっと書きやすく、XMLを解析するのとそれほど変わらないと思っています。

Rubyの最も人気のある機能の一つは、メタプログラミングのサポートです。つまり、新しいキーワードのようなものを導入するなど、言語自体を変更するかのように機能する機能です。

ルールエンジンを使用すべきでしょうか？

ドメイン固有言語（あるいはあらゆるコンピュータ言語）について話す際に、よく使われる言葉に「構文ノイズ」があります。RubyはJavaよりもノイズが少ない、または外部DSLは内部DSLよりもノイズが少ないと言う人がいます。構文ノイズとは、人々が本当に言いたいことの一部ではない、しかし言語の定義を満たすためにそこにある余分な文字のことです。ノイズ文字は、プログラムの意味を不明瞭にし、それが何をしているのかを理解するために苦労しなければならないため、悪いものです。

XMLはかなり前から存在しており、広く使用されています。実際、使用されるべきよりもはるかに多く使用されています。ほとんどのツールと同様に、XMLはいくつかの用途には適していますが、そうでないものもあります。