最近読んだ本の中で衝撃を受けた本のひとつが、「Beyond Java」。
正直なところ、私の中では、自分なりの意見を述べられるところまで消化できていない。が、ネットを検索しても、あまり日本語のレビューが出て来ないので、内容に言及しておくだけでも意味があるかと思い、軽くレビューだけしてみようと思う（単なる読書感想文ご容赦ください）。
この本は、一言で言うと、「Javaの時代は終わった」というRuby賛辞の本なのだが、非常に説得力に富んでいる。その一番の理由は、著者のBruce A. Tate氏が、非常に優れたJava wizardであることだろう。私は残念ながらBruce A. Tate氏の著書を他に読んだことが無いのだが、ちょこっと検索してみた限りでは、「軽快なJava」という本が有名なようで、Amazonでもわりかし良い評価を受けているようだ。
Bruce A. Tate氏は、本書の中で非常に思慮深く、慎重に議論を運ぶ。
- Javaが市民権を獲得した時代背景を分析し、さまざまな偶発事象が重なった結果の必然であると主張する。
- なぜ今Javaが転換期を迎えていると考えているのか意見を述べる。
- Javaの後に来るべき言語の候補をいくつか挙げる。
- 現時点ではrubyが最良の選択であると結論づける。
- 実際に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な資産はどちらでも使えるようになるわけだが、そうなったときにはどちらの方法がより選ばれることになっていくのだろうか。冒頭でも断ったとおり答えは出せないが、こんな面白い時代に生まれたことを感謝しつつ、見守っていきたい。
Special
- PR -| とおる | 2006/09/27 13:26 |
|
サンのとおると言います。この「Beyond Java」はサンの社員が一番呼んでいるかも知れませんね（笑）。どんな技術であろうとも必ず終焉を迎えるように、Javaが終焉を迎えたときに、どんな言語に置き換わるのだろうか、という観点が重要かと思います。同じロジックを書くのに、最短で簡単に書ける、Rubyがその最右翼であろう、ということでRubyが注目されているようです。 http://www.itmedia.co.jp/enterprise/articles/0609/11/news045.html 私のまったくの個人的な感想ですが、言語の流れが変化するのは、その言語が稼動する基盤が変化を起こすときなのではないでしょうか。メインフレームとCOBOL、クライアント・サーバとC/C++、WebとJava、といったように。そうすると、Javaの次の言語には、新しいコンピューティング基盤の普及が必要になるのでは、とも思います。考えすぎかなあ。 | |
| 小椋 | 2006/09/27 15:28 |
|
とおるさん、早速のコメントありがとうございます！ なるほどやはりサンの方の間ではポピュラーなんですね！これほど議論を呼びそうな内容で、出版されて１年も経つのに、なぜ日本語訳が無いのが不思議です。できるものなら有志で日本語訳したいくらいですね。 CLR上で動くIronPythonと同じ発想でIronRubyなんてプロジェクトもスタートしたばかりながら存在するようなので、よりどりみどりと言ってよいのやら、訳がわからないと言っていいのやら、楽しい(?)時代に突入しそうですね。VMによって成し遂げられたものとは違うけど、これが本当のWORAだったのか？なんて。 新しいコンピューティング基盤とともに言語の流れが変わるという考察、興味深いですね。おっしゃるとおりではないかと思います。しかし、そういう意味では、Web2.0（and/or）SOAの実現は、新しいコンピューティング基盤の普及と言えるのではないかと個人的には思います。 いつか別のエントリで、もっと考えを整理してから問いかけとして書きたいと思っているのですが、情報技術の「抽象化」による進化の歴史の中で、Javaがこの10年で成し遂げた素晴らしい仕事は、WORAの精神によるOSの抽象化だったのではないかと思います。これに対して、Web2.0やSOAが違う角度から成し遂げようとしている抽象化は、コンピュータやネットワーク自体の抽象化であり、これは今から起ころうとしている大きなコンピューティング基盤の変化ではないかと思うのですが、どうでしょうか。 とはいえ、これまで特にSOAを牽引してきたのはJavaじゃないか、といわれると、その通り間違いないと思うのですが、Web2.0版SOAである「マッシュアップ」がWeb2.0の持つアジャイルな思想に裏付けられて当たり前に展開されだした頃、何か新しいことが求められるようになるのではないかと期待しています（根拠なき妄想ですが・・・）。 | |
| 通りすがり | 2006/09/28 23:47 |
|
記事、大変興味深く読ませて頂きました。 言語の潮流であるとかコンピュータ基盤の進化というような高次の議論をされている処恐縮ですが、少し引っ掛かった点があったのでコメントさせて下さい。 現在のJavaが抱える問題の一側面として著者が挙げていると紹介されている点である「XMLに頼りすぎて複雑化してしまったこと、習得にえらい時間がかかる程に肥大化してしまったフレームワークが存在すること」という箇所ですが、個人的には少々違和感を覚えます。 どんなシステムであっても相応の作り方というのがあると思いますし、「Web+DBでさっさと作るアプリケーション」であるならJavaでもそのように作れば良いだけの事では無いでしょうか。 確かに現在、Javaで利用できるフレームワークやライブラリ、ツール類の中には高機能化複雑化したものも多いですが、XML云々の下りに関しては「JavaでHelloWorldを書くだけ」なのに、「皆が使っている、流行っている」というだけで無理にStrutsやHibaneteを組み込んで「ややこしい、面倒臭い」と言っているだけのように感じました。 と、原典を読んでもいないのに偉そうな事を書いてしまいました。当方の内容理解が間違っておりましたら何卒ご容赦下さいませ。 | |
| 小椋 | 2006/09/29 13:43 |
|
通りすがりさん、コメントありがとうございます。 仮に、perl+CGIとjava+Strutsを比較しているのであれば、おっしゃっていることは正しいのだと思いますが、筆者は例えばruby+Railsとjava+Strutsを比較したときに、XMLその他の分だけjava+Strutsがめんどうくさい、と指摘しているのではないでしょうかね？ つまりフレームワークの強みを持ち、かつ従来の方法より飛躍的に生産性の高い方法が登場しようとしている、特に強く言い、警鐘を鳴らしたいんだと思います。 本の中では相当なページ数を割いてjavaで書くとこうなのがrubyで書くとこんなに簡単・・・というような内容に割かれています。 | |
| 小椋 | 2006/10/13 18:58 |
|
小椋です。 | |
| 小椋 | 2006/10/23 18:42 |
|
「RubyCLR」の開発者ジョン・ラム氏が1月からMicrosoft入り、という記事が本日付けのITmediaに出てました。 「RubyCLR」と、エントリ中に出てくる「IronRuby」の比較については、 | |
| 小椋 | 2006/11/08 11:26 |
|
上記のJoel on Softwareの書評記事を翻訳してみました。 | |
ストレス社会との付き合い方
「思いやり経営」のススメ
テレワークが労働者のマインドを変える
求む、クックパッド男子
37歳の常識――我々は一生学び続ける