書評：Beyond Java
From The Joel on Software Translation Project
Joel Spolsky / 小椋一宏 訳
2006年10月12日 木曜
私のような「年食ってもうろくしたプログラマ」たちが、なぜ出現したての新しい面白そうなプログラミング言語をなかなか使いださないのか、またなぜ本やコンサルティング契約をどんどん売るようなイカした売り出し中の手法を白い目で見るのか（もし私があなたの新しい本「エクストリームUMLリファクタリングパターン」に関心が薄すぎるように見えたらごめんなさい）、30歳以下のプログラマーは疑問に思うだろう。
それは多分、私たちが「銀の弾丸はない」を読んでいるからだ。はるか昔1986年に、Frederick P. Brooks（伝説の「人月の神話」の彼だ）が書いて、その後何度も何度も歴史が的確さを証明した、電撃的に重要なエッセイだ。
プログラミング作業とは、二つの難しさを乗り越えることだ。
すなわち、不適切なプログラミングツールを使っていることに起因する本質的でない難しさと、どんなプログラミングツールや、プログラミング言語を使っても解決できない、本質的な難しさだ。本質的でない難しさの例としては、手動でのメモリ管理（"malloc"とか"free"とか）や、Javaでトップレベル関数が無いために作られるシングルトンクラスが挙げられる。本質的な難しさの例としては、プログラムの中の異なる部分同士の微妙な相互作用をなんとかすることが挙げられる。例えば、新しく追加した機能が他の部分にどういう結果をもたらすかを把握することなどだ。
本質的でない難しさは、プログラミング言語の進化によって駆逐することができるが、そのあとには、ソフトウエア開発における本質的な難しさだけが残される。「銀の弾丸はない」理論は大まかに言って、新しい技術によって得られる効果は、次第に減衰していくだろう、と警告しているのだ。私はここでBrooksの議論を本気で評論するつもりは無いので、もし「銀の弾丸はない」を最近読んでないなら、是非読むことをおすすめする。
1950年代から、本質的でない難しさを駆逐するために、５つの大きな進歩があった。これらは、おおざっぱにいって、以下の通りだ：
- アセンブラ
- 高級言語（Fortranを含む）
- 構造化言語 (Algol-60とC)
- 宣言型言語 (SQLを含む)
- メモリ保護型言語 (Lisp, VB, Javaを含む)
6番目には何が入るのだろうか？
Bruce Tateの本、Beyond Javaはそれを扱おうとしていて、どうしてこんなにたくさんの経験あるJavaプログラマーがJavaにうんざりしてPythonやRubyに移っていくのかについて、うまく説明できている。
56ページと57ページでは、この本の著者ではないが、重要な脇役を演じているSteve Yeggeが、リストをひねり出している。この2ページは、この本の中でも最も重要な2ページだ。なぜならリストにあるそれらの問題こそ、PythonとRuby（そして、一般にちゃんと評価されてないけどJavaScriptが）が、実際に解決した問題だからだ。
Steveyは、Javaにおける本質的でない難しさをたくさん挙げているが、読み進めるうちに、明示的な型宣言という一環したテーマに気づくだろう。プログラマーが型を宣言することを求められて、上記の問題につながるそれのことだ。例えば、データをJavaで表現できないことのほとんどは、単に、型が明示的に宣言されなければいけないことの副作用だ。そう、Javaには他の問題もあるが、これが問題の、巨大なヤバい核心部分だ。
歴史家にとっては、型宣言は、良いプログラミング言語が駆逐できる非本質的な問題の一つのであるように見えはじめてきただろう。Beyond Javaは、この議論をよくまとめており、一読の価値がある。
(オリジナル: Book Review: Beyond Java)
