Groovy について考えてみる

日本語サイト (http://xpc.aa0.netvolante.jp/groovylab/space/snipsnap-index)

adasさんに示唆されて。

まあずっとこの手のスクリプト言語ってネイティブコンパイルする言語使ってて Lua が使いたくなるシーンでそのまま使えば良いのだろうと思っていた。実際 Java でそういうことがしたいシーンは C/C++ でそういった欲求が起こることより多い。例えば Ant タスクなんてのはまさしくそうだと思っていて、 C/C++ で開発する時は間違いなくスクリプト言語の助けを借りたいシーンだ。でもなんとなく Java から Runtime.exec を呼ぶのはは VM 教 (一度苦労して動かした VM を利用しないなんて愚かなことだ！) やクロスプラットホーム教 (せっかくのクロスプラットホーム性を本質と関係ないところで崩すなんて！) の教えを破るみたいで抵抗あるし、そもそも外部プロセスとのある程度の連絡が欲しい場合もある。それに Reflection があるので Java リソースとのブリッジは特に意識しなくてもかなりできるはず。そうそう UnitTest をコンパイル言語で書くというのも常々愚かなことだと思ってまして、あんなもんスクリプト言語で書けるにこしたこと無い。ああそれに Webアプリもいちいちコンパイルしなおす必要が無ければどれだけ開発イテレーションが速くなることやら。

Java で動く ECMAScript 処理系なんてのはそういう目的が実にはっきりしてるのです。スクラッチから言語を起こした理由は FAQ の Why Groovy? (http://groovy.codehaus.org/faq.html#why-groovy) を見るに、 Java 開発者にとって Java に似てるのは良いことだ、 Java のクラス構造と言語の内部クラス構造が一致してるのは良いことだ、と、ええと完全に正しい道を歩んでやがる感があるなあ…

なんて思いつつ feature を眺めてみると…驚く程食指が動かないんだよなあ… Java のこういういかにも「おしごとにつかいます」的な雰囲気は嫌いなんだよ (もうほとんどあてつけにしかなってないと自覚してますですすいません)。

closure: Ruby 見慣れた人間には普通。デフォルトで it 予約語で引数渡しというのが少しヘンか。 (http://groovy.codehaus.org/closures.html)

GPath: D の with を書きにくくした感じか。 D のあれは namespace の局所的明示的に破壊するわけだけど、 closure 使ってやってる分汚れは無いけど書きにくい感が。 (http://groovy.codehaus.org/GPath)

GroovyMarkup: DOM を native で持っている。 XML 一色文化な Java では普通にありがたいかと。 (http://groovy.codehaus.org/GroovyMarkup)

あと Groovlets とか Groovy Sql とか Groovy Beans とか見る気も起きないな…おしごとおしごとしてやがるので。バイト中に読もうか。雑なメモでした。