「Beyond Java」

　最近読んだ本の中で衝撃を受けた本のひとつが、「Beyond Java」。

　正直なところ、私の中では、自分なりの意見を述べられるところまで消化できていない。が、ネットを検索しても、あまり日本語のレビューが出て来ないので、内容に言及しておくだけでも意味があるかと思い、軽くレビューだけしてみようと思う（単なる読書感想文ご容赦ください）。

　この本は、一言で言うと、「Javaの時代は終わった」というRuby賛辞の本なのだが、非常に説得力に富んでいる。その一番の理由は、著者のBruce A. Tate氏が、非常に優れたJava wizardであることだろう。私は残念ながらBruce A. Tate氏の著書を他に読んだことが無いのだが、ちょこっと検索してみた限りでは、「軽快なJava」という本が有名なようで、Amazonでもわりかし良い評価を受けているようだ。

　Bruce A. Tate氏は、本書の中で非常に思慮深く、慎重に議論を運ぶ。

1.Javaが市民権を獲得した時代背景を分析し、さまざまな偶発事象が重なった結果の必然であると主張する。

2.なぜ今Javaが転換期を迎えていると考えているのか意見を述べる。

3.Javaの後に来るべき言語の候補をいくつか挙げる。

4.現時点ではrubyが最良の選択であると結論づける。

5.実際にrubyを使った場合にどれだけ生産性が上がるのかを定量的なデータで示す。

　ダメ押しに、20ページに一回ぐらい筆者以外のJava wizardのインタビューが出てきて、なぜJavaが駄目なのかを語らせ、筆者の主張の客観性を裏付けるという念の入れようだ。

　その要旨をブログのエントリでまとめるにはちょっと論点がたくさんありすぎるのだが、あくまでも僕の印象という前提でまとめると、こんな感じだ。

·       Javaは、C++とインターネットのもたらした混乱の中で、たまたま絶妙なバランスを持ったC++の最適な後継者として生まれ、市民権を勝ち取った

·       が、時代の変化とともにその絶妙なバランスが通用しなくなってきている。C++を引きずりすぎて完全なOOP言語になれなかったことや、（コードブロックやcontinuationのような）新しい概念を採り入れられなかったこと、XMLに頼りすぎて複雑化してしまったこと、習得にえらい時間がかかる程に肥大化してしまったフレームワークが存在することetc...が、現代最も必要とされている「Web+DBでさっさと作るアプリケーション」に向いてない

·       特にstatic typingと組込み型は最悪に非効率だ

·       とはいえ、VMはすばらしい考えだった。Javaは死なず、システムに近い部分では生き残る

·       rubyはVMが無い以外は現時点で最もイケてる

·       Javaで書いたプロジェクトをrubyで書き直してみたら生産性は30倍だった

·       Java技術者は他の言語も勉強しよう

　そんなわけで、これを読むと大抵の人は、ああそうかもうWebのプロジェクトでJavaを使う時代は終わったんだ、と納得させられてしまうと思う。Java登場までの歴史がまとまっているし、いろんな言語が並べて一口批評されてあるので、現代のプログラミング言語の歴史と、長所短所をざっと把握する意味でも面白い。

　自分にとっては筆者の指摘は概ね納得できるものだったが、自分がJava界の住人ではないせいか、一点読んでいて納得がいかない部分があった。virtual machineを絶対とする観念だ。筆者はrubyの最大の欠点がJVMの上で動かないことだとしている（もっとも、最新版のJRubyはRailsを動かせるぐらいまで来ているらしいが）。

　はじめに考えたことはこうだ。筆者がJavaの欠点として語る、習得に何年もかかるようになってしまった、というJavaの複雑性は、JVMの発明により過去との断絶が起こった結果、必然的に全てのものをオブジェクト指向で設計しなおさなければならず、抽象化が幾層にも重なったところにも一因があるのではないか。

　Cで書かれたPHPやperlは、なまじ過去の資産が生かせるので、既に開発されたライブラリ関数を最大限に生かそうとする（例：ここ）。JVMによる過去や他世界との断絶は、車輪の再発明を生み、なおかつ車輪を作る方法をエレガントでエンタープライズな方法に限定してしまったのではないか。車輪がどんどん発明されているのだから、それを使えるアーキテクチャは尊重すべきなのではないか。

　だがすぐに、私の言っていることは結局のところ単に「多少言語の整合性を犠牲にしてでも、過去との互換性を保つことによる効率性が大事なのではないか」という意見であることに気づいた。

　これは概念的には筆者が述べているC++の欠点（過去との互換性を重視し完全なOOP言語になれなかった）であり、Javaの欠点（C++との記法互換性を重視し完全なOOP言語になれなかった）であるし、直接的には筆者がC++の欠点として挙げているDLL地獄をもたらすものそのものである。そもそもこの本はそれを否定するところから始まっているのだから、そんなことを言っても意味が無いのだ。

　筆者はrubyが最終解ではないとしているが、仮にrubyが現在のところ他を圧倒する現代的な文法を備えているために高い生産性を提供し、rubyがJRubyで筆者の言うJVMで動かない欠点を克服したとすると、ユーザーにはJVM資産を利用する方法と、UNIX/Windowsの各プラットフォーム資産を利用する方法と、平等な選択肢があたえられることになる。

　もっと言うとpure rubyな資産はどちらでも使えるようになるわけだが、そうなったときにはどちらの方法がより選ばれることになっていくのだろうか。冒頭でも断ったとおり答えは出せないが、こんな面白い時代に生まれたことを感謝しつつ、見守っていきたい。                  

                                         07日语 刘若凡