1つの言語

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

開発における言語は１つだけにするべきか？

ソフトウェア開発の際に1つの標準言語に集中することが、ここ10年の間ほぼずっと、エンタープライズ・ソフトウェア界における流行であった。多くの開発組織が、すべての作業をJava(もしくはC#/VB)でこなそうとしている。

その理論的根拠は、開発者が複数の言語に熟練するのは困難だということだ。単一の言語にこだわれば学習の負荷は下がる。とりわけ新人を採用するときにはそう。

まったくの嘘というわけではないが、ほとんど大はずれだ。プログラミング環境ってのは一部は言語だけれど、でも複数の言語やフレームワークについてでもある。大規模フレームワーク、HibernateやStrutsやADOなんかは、単一のホスト言語でプログラミングしていたとしたって、今や1つの言語を学ぶのと同じぐらい難しい。何をしないといけないのかをホスト言語で書き表す難しさが相当やっかいなため、多くのフレームワークが設定ファイルに頼っているなんてこともしょっちゅうだ。そしてその設定ファイルは事実上、XMLで記述される外部ドメイン特化言語であり、プログラミング・カクテルに醜さの火酒を1ショット混ぜることになる。

多くの開発者にとっては、1つの言語という発想はプロ意識の欠如の表れだ。毎年1つは新しい言語を学べという『達人プログラマー』の教えがその何よりの裏付けだ。その教えのポイントは、プログラミング言語はプログラミングについての考え方に影響を及ぼすもので、新しい言語を学ぶことは、問題を別のやり方で解くことを考える大きな手助けとなるということだ。(この利益を得るためには差異の大きな言語を学ぶことが大事だ。JavaとC#では似たもの同士すぎて有効でない。)

『達人——』のこの教えにはほぼ同意する。ただ、新しい言語を学ぶオーバーヘッドについても同意する。私個人のスクリプトはほぼ全部がRubyだし、PythonやGroovyやPowerShellといった適当な代替物では遊ぶ以上のことをする気がおきなかった。それらの代替物は難しくて使えないというわけではないが、Rubyを知りすぎているせいで、代替物だと調べものをしないといけないことが億劫なのだ。

重要なのは、そういったスクリプトを書いているときは、新しい抽象概念を扱っているわけではないということだ。私がやっていることの多くは、テキストや、ファイルシステムや、XMLかYAMLの塊なんかをいじることだ。もし相当な規模の新しい抽象概念を扱わないといけないのならば、その概念を扱う手段として、ライブラリの使い方を学ぶコストが言語を学ぶコストよりずっと小さいなんて事ははない。もし有向グラフ構造の表示を指示したいと思ったなら、GraphvizのDot言語を学ぶことが、Rubyの新しいライブラリを学ぶより大変ということはほとんどない。

ライブラリの代わりにDSLを使うことで、抽象概念をよりよく扱うことができる。おかげで書いたものが見やすくなり、意図を示しやすくなる。APIは語彙の宣言のようなもので、DSLは理路整然とした文章を書くための文法を追加する。

この論はDSLを強く擁護するものだが、汎用言語にも当て嵌まるのではないだろうか？もしJavaで(または、もうすぐC#でも)作業しているなら、そのプラットフォームで利用できるのだから、Rubyを使うことに意味はあるか？

ここ10年はメモリ管理を行うCベースの言語の発展が見られた。人々はメモリ管理に長年懐疑的だったにもかかわらず、それがすばらしいもので、エンタープライズ界においてCやC++から決別する価値があったことを知った。共通のプラットフォームや言語は、PowerbuilderやDelphiのようなプロプライエタリの閉ざされた楽園からも人々を引き離した。

同様の疑問がある。近代的なスクリプト言語はさらなる前進なのか？それらの厳選された簡潔さを私たちは好むのか？私は何度となく、熟練したJavaやC#の開発者が、Rubyだとより効率的であると報告するのを耳にした——だから私はRubyを勧めているのだ。数年以内に別の言語でも同じような報告が現れたとしても、私は驚かないだろう。

10年前、OOPSLA 96で古い友人のTom Hadfieldと話し合ったときのことだ。Javaの隆盛は目に見えていて、Smalltalkの未来が絶望的なのは明白だった。私はSmalltalkラヴだったにもかかわらず、かなり楽観的だった。私は、Javaが人々に望みのものをくれたと感じていた。Smalltalkほどすてきではなかったが、C++よりも充分によいものだったし、特にメモリ管理については気に入っていた。Tomは同意せず、Smalltalkの表現力とは何かが根本的に違うと感じていた。Smalltalkにはやろうとしていることの意図をコードに直接記録できる方法——ドメインの知識とプログラミングとのギャップを埋めるもの——があった。

それからの年月で、結局Tomが正しかったという見解に達した。中かっこ王国での数年を経た後に、私に足りなかったものをRubyが気づかせてくれた。Rubyのコードは明快に読むことができるので、より簡単に作業することができる媒体となっている。ツール類が劣っていたとしてもだ。Smalltalk嫌いに対して、私は以前よりもずっと同情を感じるになった。イメージファイルを怒りながら開くなんてことはしたくないと長年思ってきたのだけれど。

さて、私たちは80年代後半から90年代前半にかけてのの言語不協和音時代に戻ろうとしているのだろうか？私たちはいくつもの言語が舌戦を繰り広げるのを見ることになると思うが、そこにはかつてとは大きな違いがあるだろう。80年代後半では言語を密接に相互運用することは困難だった。最近では、異なる言語が密接に共存することができる環境を作ることに注目が集まっている。スクリプト言語は伝統的にCとの親和性がある。JVMやCLRといったプラットフォーム上での相互運用には多くの努力が注がれている。言語のライブラリにはとても多くの投資がされてきたので、それらを無視することはできないというのが、その潮流の原因のひとつである。

そういうわけで私が思うのは、今日フレームワークを選ぶのと同様に、人々が出来ることに応じて言語を選択し、プロジェクトにおいて複数の言語が使用されるようになるだろうということだ。多言語プログラミングの時代に突入しているというNealの意見に私も賛成する。