Javaの理想は好き、でもJavaの現実は嫌い

http://amrita.s14.xrea.com/d/?date=20031121#p01

とっても共感。リンク先の議論にも共感。「圏外からのひとこと」は、今読んでいて最も興味深い日記の一つです。

この２つの文章をきっかけに、「PHP+SQL」はなんでラクなのか、そのラクさは何を起源にしていて、トレードオフは何なのかを整理してみる。

RDBMSを（難しいことを考えずに）手軽で便利な永続性／データ集合演算エンジンとして使おうとすると、PerlとかPHPならば、あまり深く考えなくても、自言語側のデータ構造にマップできる。このため、従って、RDBMSの強力な部分を素直に使うことが出来る。これは、データ保持はバイトストリームが基本でその上で評価方法がコンテクストによって異なるという、ゆるやかな型システムの恩恵だと言ってよいだろう。この仕組みは、他の環境下のデータ（RDBMSデータ/CGIのパラメータ)を扱う上で、思ったよりも重要なのかもしれない。

これに対し、強い型付けがある言語は、たとえばSQLや別の言語システムのように、自分とは異なるシステムとの間で、型マッピングをしなくてはならない。これはとてもとても大変です。RDBMSとの通信だと、型だけじゃなくて、O/Rマッピングの際のインピーダンス・ミスマッチもあるし。

そんなわけで、JavaでJDBCを使ってコードを書くと、なんとも釈然としないコードになってしまう。Java的には「SQLを使わないで作ったらこんなふうにきれいに書けるのに、SQLを使うようになったとたんにキモチワルクなるなあ」となるし、RDBMS的には、SQLの世界で素直に書ければいいのに…と考えてしまう。

とはいえ、柔軟さは欠点でもあり、実行効率やスケーラビリティなどの問題はつきまとうだろう*1。バイト列/テキストの範囲で処理出来ないデータを交換するようになったら破綻するのではという話もある（XMLの出番かもしれない）。たかがStringにだって、文字コードというメタデータがあるのだ。

さて、異機種間接続におけるOO言語的回答は、他のシステムとのコネクタを作ればよいということになるだろう。RDBMSを例にすると、RDBMSの世界をオブジェクトとして透過的に扱えるようにするフレームワークを作るという方向性だ*2。でも、なんだか手間ばっかりめちゃくちゃかかって*3効果はなんとも不明確。これならSQLを直接書いたほうがナンボかマシだと思っても不思議ではない*4。

ほんと、どうにかならんのかなぁ…。Javaに、コンテクストによって多様な振る舞いを可能とするようなゆるい型付けの世界を導入できないか。…と考えるよりは、RubyやPHPやPerlみたいな世界に、強い型付けのパワーを導入するという方が正しい気がしてきた。一旦強い型の世界で全てを作ってしまうと、弱い型なんて受け入れ不可能だよな。こういう方向性で考えると、libruby + (subset of C++) = c.succというアイディアがよく分かる。

あと、こういう問題は、XMLにおける貴族とボヘミアンの対立にも通じる部分があるな。思想的には、UNIXと汎用機の対立、という意見もどっかにありました。扱うデータがバイトストリーム/テキストならば、あとでアプリによってどうとでも解釈できるから異システム間の最低限の相互運用性が容易に確保できるというUNIX的考え方。

これは、そのまんまPerlやPHPに引き継がれてる。Javaには、無い。無くてもいいものなのか。どうだろう。

*1:JavaにしろPHP/Perlにしろ、ネイティブなバイト列の世界に対して様々なものを付け加えているという意味では、抱えている問題は同じともいえるかもしれない

*2:古くはTopLinkなんかあったし（いや、今もあるが）、今だとTorqueやEJBだってそうだよね

*3:使ってると「なんでこんなめんどくさいことやらにゃならんねん……直接SQL書いてそれがそのままオブジェクトになってくれてもいいのに……」とか思ってしまったりする。しかし、表定義ベースの思考の延長線上でそうなってしまうと、それはそれで、Java的にはなんともキモチワルイことになってしまうのだ。クラスと表定義は、決定的に違うのだからして…

*4:SQLJは流行らなかったが