ドメイン特化言語は英語のように書くべきではない

作者 Sadek Drobi , 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年4月11日

セクション

デベロップメント,

設計/アーキテクチャ

トピック

Architecture ,

設計 ,

Domain Specific Languages

タグ

ActiveRecord ,

Business Natural Languages

良いドメイン特化言語 (DSL) とは、プログラマ以外でも読むことができる英語のようなものだと広く言われている。Dave Thomas氏は、DSLは自然言語にできる限り近づくものではない(source)と主張し、そのような考え方に反対する。 さらに、これをDSL設計の指針とすることがむしろ有害であると主張する。また、彼が信じていることがDSL設計では重要であることを強調し、必ずしも英語らしくなくてもうまくいくDSLの例を紹介している。

Dave氏によると、DSLは英語や他の自然言語に近づく必要はない。なぜなら、それは実際に自然言語を話さないドメイン専門家など、かなり特別なカテゴリやユーザを対象にするからだ。

ドメイン専門家 [中略] は業界内の専門用語を話します。それは、彼らが仲間同士で効率的にコミュニケーションするための簡単な表現として発明した特別な言葉です。専門用語は英語を使うかもしれません。しかし、英単語にまったく異なる意味をつけて使っているのです。その意味はある分野の経験を通してのみ学ぶことができます。 

このように、DSLは専門用語を反映し、簡潔な方法でドメイン専門家の専門知識を表現すべきである。依存関係を管理するMake、コードでデータを表現するGroovy builder、Rubyでデータモデリングを行うActive record の記述などは、ドメイン専門家にとってDSLが必ずしも英語らしくある必要がないことを示す数少ない成功例である。例えば、has_many や belongs_to のように、Active record の記述でいくつかの命令文が英語のようであっても、実際はそうではない。それらは「モデルの世界の専門用語」であり、「コンテキストに特別な意味を持つ」ものである。

Dave氏の意見によると、もうひとつの重要な点は、「ドメイン専門家」はビジネスユーザとしてではなく、むしろ仕様書を書いている人として考えるべきだ。 彼らはプログラマである。本当は英語のような言語など必要ではない。Dave氏は、実際に流暢なインターフェースの概念は誤解されることが多いと考える。「ここで言う流暢さはプログラマの流暢さであって、英語の流暢さではありません。簡潔で表現に富むコードを書くことです。」

Dave Thomas氏は、自然言語に近づこうとすることは必要ないばかりでなく、有害でもあると主張する。自然言語は正確ではない。 これは現実世界では力を持つが、プログラミングに当てはめることはできない。だから、「自然言語のように見えるDSLを作ろうとすると、いつも期待通りにならない」のだ。どんなに頑張っても、シンタックスは「まったく英語らしくなく」なりがちである。そして、このギャップがかなり分かりにくいのだ。

ここに認知的不協和があります。まず、自然言語で表現されたアイデアを持ち (問題) 、 それを人工的な言語 (AppleScriptプログラミングモデル) に当てはめ、偽の自然言語のようなものを書かなければなりません。

問題になる点を示すため、Dave氏は、test/specフレームワークを使って書かれたテストからコードを抜き出して例を示し、１つの式を分析している。

@result.should.be.a.kind.of String

これは英語のように読めます。しかし、実際はそうではありません。最後の２つの単語がスペースで分けられている以外、単語はピリオドで分けられています。プログラマとして、私はなぜだか知っています。しかし、ユーザとしてはそれが気になります。最初の例で、@result.should.be.a.kind_of と書きます。なぜ kind.of ではないのでしょうか。もし、浮動少数がおおよそ等しいというテストが必要ならば、@result.should.be.close value と書いたでしょう。なぜ、close.to value ではないのでしょうか？ 

これは取るに足りない詳細なことですが、それでも英語の知識を使ってただテストを書くことはできないということを示しています。よく調べなければならないのです。そして、もしそうしなければならないならば、なぜ仕様やテストのドメインにより近い言語やAPIを使わないのでしょうか？

英語のようなDSLの方が読みやすいというのは本当だが、Dave氏は「DSLの自然言語的な感覚を作り出そうとすることで、抽象的なことが扱えなくなる。」と指摘する。コードが読みやすくなるかもしれないが、「書きやすさがなくなり」、「不確かさとあいまいさが増える」のだ。

二番目に、このように書いていることに気づきます。

def a
self
end

「a」をコネクタとして使うことができます。

add.a.diary.entry.for("Lunch").for(August.10.at(3.pm))

一線を越えたことがわかるでしょう。これは、もはやDSLではありません。片言英語です。

Dave氏のブログのコメントで、Has氏もまた、プログラマ以外の人に読めるような言語にしようとすると、「読み込み専用言語」になる危険性があるとの考えを示した。彼はAppleScriptの例を挙げている。AppleScriptは、読みやすくするために「言語のセマンティクスを記述するお決まりの記号的なものをほとんど」削除する必要があった。結果として、「構文は、言語のセマンティクスを明確にするのではなく、事実上混乱させる」ことになる。「AppleScriptを読んで、_what_ が何をするか理解するのはとても簡単だとしても、_how_ が何をするか正確に理解するのはかなり難しい」のだ。

Has氏は英語のようなDSLを使うことから起こりうる別の問題点を指摘する。：ユーザは、「英語のように見える(_looks_)から、英語のように振舞う(_behave_)。」と思うかもしれない。そして、「英語のようであることに強く関連付けて結論を出してしまう。しかし、実際はそれで終わりではない」のだ。 このように、Has氏によると英語のよう見えることは「意図せずにユーザに非現実的な仮定を促す」ことになる。

もし、DSLの読みやすさと表現力に興味があるならば、Dave氏のブログ(source)でもっと他の例やコメントを見つけよう。

原文はこちらです：http://www.infoq.com/news/2008/03/dsls-are-not-natural-languages 

• 次へ >