「グッドラッパー」ＶＳ「セカンドシステム症候群」

本日、「第2回 grails code reading」に参加いたしました。
私にとっては、懇親会を含め(懇親会のほうが？）大いにインスパイされる、有意義なものでした。参加者の皆様および、会場を提供いただいたＣＩＪさまにおかれましては、ありがとうございました。

帰りながら思うに、GrailsとRailsの関係というのは、「ソフトウェア(J2EE技術群)の複雑さの増大」に対するアンチテーゼとしての典型的な２大アプローチをそれぞれに代表しているのだな、と思いました。ひとつは、バッドノウハウ *1に対する「グッドラッパー的アプローチ」（グッドかどうかは置いとくとして、ラッパー的アプローチ）としてのＧｒａｉｌｓ、「セカンドシステム症候群」気味にシンプルなものに立ち戻ろう、という立場のRails、です。

ＩＴ業界２大ドグマの対決というわけです*2。この認識からいえるのは、Ｇｒａｉｌｓについては、「ラッパーがラッパーとして、どこまで隠し通せるの？」という程度問題に直面するだろうし*3、Ｒａｉｌｓについては、今は単純でも、ユーザーが増え、適用領域が増え、一般性が要求されるようになったときにどこまでシンプルさが維持できるか、という問題になります。いずれにせよ、あまり良い未来が予想できない構図ではあります。

後で書く：

静的オブジェクト指向に慣れ親しんだＪａｖａプログラマが、動的オブジェクト指向の世界に移行するためには「２つの壁」があるはず。それがGroovyがすんなり業務現場に広まるかどうかのキーポイント：
１つの壁は、思考習慣としてのテストファースト・テストドリブン、が普及すること。受託開発ではこれらは必ずしも普及してない。
もうひとつの壁は、「動的に変化するオブジェクト」ダックタイピングへ思考を切り替える（静的タイピングにまつわる既得利益を放棄させること）ことについて。これについては、「動的にJavadocを生成する」様な考え方も一助となるかなと思いました。emacsのドキュメントコメントのように*4、Groovyで「インスタンス（に結びついたメソッド）に関する」APIリファレンスドキュメントを動的にメタクラスとかを使って返せるように作れないかなーという話。