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は流行らなかったが
…と、まあ
誰かがどっかで書いたような文章になってしまった気もするが、自分で整理してみることも悪いことではないだろう。たぶん。
「圏外からのひとこと」のessaさんから
リンクしていただきました。ありがとうございます。なんかすごいイキオイで人が来てます…（←びびってる）。しばらく置いてから読み直したら文章がめちゃくちゃだったんで、ちょっと手直ししてます。
http://juno.style.ne.jp/hiki/hiki.cgi?SpringFramework
これは、先に書いた文章の「フレームワークは手間ばっかりめちゃくちゃかかって効果はなんとも不明確」という部分に対する、一つの解決策だと思います。先に書いた文章では、手間と効果についてのみ述べましたが、この文章にはEJBなどの重いフレームワークにおけるその他の問題も語られていて、とても勉強になりました。
Development Style Round Table Talking 第1回 オブジェクト指向の弱点
http://www.atmarkit.co.jp/fjava/devs/roundtable01/roundtable01.html
冒頭からOOによる実装技術の弱点の話題ですー。この問題意識は広く共有されている…というよりは、ワタシがJavaWorldの浅海さんの記事から学んだことだということでしょう。
浅海 オブジェクト指向とXML（の融合）を考えるときに重要だと思うのは、キャッチーないい方をすると「バリューの復権」という言葉に集約されるのではないでしょうか。バリュー（値）はもともとモデルにとって重要な要素だったのですが、オブジェクト指向は、バリューはほとんど無視して、オブジェクトのみを重視する考え方なんですね。
この部分にグッときまくりです。RDBMSにSQLを発行して得られる結果セットは、場合によっては正に値以外の何物でもなくて。OOの枠内では、解決できないわけじゃないけどなんとも収まりが悪く、キモチワルイ感覚が残ってしまうということなんですよねぇ…。
