http://martinfowler.com/bliki/BusinessReadableDSL.html

ビジネスピープルは、DSLを使えば、プログラマがいなくてもソフトウェアのルールを書けるのだろうか？

DSLの話になると、ビジネスピープルが自分でコードを書くのかといった話によくなる。 こうした考えには、COBOLのインターフェースの話を持ち出そう。 元々のCOBOLの目的は、プログラマがいなくてもソフトウェアを書けるようにすることだった。が、結果は見ての通りである。 プログラマがいなくてもコードを書けるという話には、COBOL（とその他大勢）が失敗したところを、今回はどうやって克服するのかと尋ねるようにしている。

私は、プログラミングには特殊なマインドセットが必要だと考えている。 それは、マシンに正確な指示を与えること、そして、そうした膨大な指示を構造化して、理解可能なプログラムにすることである。 この素質が、そしてプログラムの理解と構築にかかる時間が、長年にわたってプログラマがコンピュータとビジネスピープルの間に存在し続ける理由である。また、多くの「非プログラミング」環境が、プログラマという立場を繁栄させているのである。

とはいうものの、ビジネスピープルが直接DSLのコードを書くようになったときに、DSLの最大の利点が発揮されると思う。 ただ、そのスウィートスポットは、 ビジネスライタブルなDSLよりもビジネスリーダブルなDSLの方だろう。 ビジネスピープルがDSLのコードを見て理解できれば、ソフトウェア開発とそのドメインとの間に、深く、豊かなコミュニケーションチャンネルを構築することができる。 ここはソフトウェア業界での大きな亀裂である。 DSLがこれを克服する助けになれば、非常に価値のあることだろう。

ビジネスリーダブルなDSLがあれば、 プログラマは書いたコードを その意味を理解できるビジネスピープルに 何度も確認してもらうことができる。 顧客は自分で変更を加えることもできるし、 コードの下書きを書くこともできるだろう。 しかし、コードを清書したり、デバッグやテスティングをするのは、プログラマである。

ビジネスライタブルなDSLには利点がないと言っているのではない。 数年前に私の同僚が、ビジネスライタブルなDSLを備えたシステムを構築したが、それはお客様に大変喜ばれている。 ただ、ある程度の開発環境（意味のあるエラーメッセージ、デバッグツール、テスティングツール）を整えるのはコストが膨大にかかってしまうのだ。

プログラマを蔑ろにしようとするツールをdisるのに、すぐにCOBOLのインターフェースを例に挙げてしまったが、大きな例外を認めなくてはならない。表計算ソフトだ。 驚くことに世界のビジネスはExcelで動いているのだ。 プロのプログラマはExcelを見下すことが多いが、もっと真面目に向き合わねばならない。 そして、なぜExcelが成功を収め、今も成功しているのかを理解するよう努めなければならない。 その理由は、多くの言語ワークベンチ開発者を動かし、 ソフトウェア開発に異なる視点を提供していることと関係しているはずだ。