G*ワークショップ 2013新春SP #jggugにいってきました。報告はid:orange_cloverさんのこちらを。
メインとして、@_y_u_さんによる、GG純度100%のとても濃いGGEXの参加報告がありました。興味深い数多くのセッション紹介があり、後でいくつかは元セッションを動画で見てみるつもりです。GroovyよりGrailsの方が人気高いんですねー。
わたしも最後のLTに参戦。「これはLTじゃねー」という怒号に包まれながら以下を発表しました。
主催者の迷惑を鑑みず、これだけは伝えたかったのは、「Groovy 2.1.0は凄い」ということです。何度でも言いますね。「Groovy 2.1.0は凄い」
Groovy 2.1.0のカスタム型チェック拡張を見ると、Groovyの位置付けに関する「野望」を感じたりもします。
これを使うと動的言語であっても、「静的型チェックをあきらめない」ことができます。ビルダーや実行時メタプログラミングを使っても、それを静的型チェックや補完に使うことができます。
Groovyは、Javaと連携したりそれをあくまで補助するものであり、Javaを置き換えるものではない、というのが従来までの位置付けでしたが、Groovy 2.1.0の方向性によって実現し得る未来を想像すると、必ずしもそれに留まらず、静的型チェックの発達したGroovyにはJavaと比較して足りないところがほとんど無くなるので「言語レベルでのJava」を使う理由が消失するのではないかと思います。「Javaの後継者」はScalaが目指してはいるものの、今のところ占有者の無いニッチでもあり、興味深いところです。
枠組みの話としては、Groovy2.0までの従来の「静的Groovy」は、「従来の動的Groovyに静的型の性質を持った静的Groovyを導入する」というものでしたが、2.1.0のカスタム型拡張では、実行時の振舞いとコンパイル時の振舞いを密接に連携連動させることができるようになります。Groovy 2.0も、Groovy++の@Typedも、「従来のGroovyに静的Groovyを加える」という考え方であり、コンパイル時と実行時はやはり断絶されたものでした。しかし、Groovy 2.1.0が垣間見せてくれる世界は、両者が併存・使い分けするだけではなく、敷居なく連携する世界です。
たとえば、開発対象のシステムが、コンパイラの振舞いを拡張したりカスタマイズしたり制御できるようになり実行時とコンパイル時が融合していく状況です(まあこれはリフレクション・タワーの話で、もっと言えばSmalltalk 80とかで実現してるんですけども)。開発対象システムの一部として定義されたType Checking DSLを、Groovyコンパイラがコンパイル時に解釈実行するというのはそういうことの発端です。
さらにその自然な発展として、プログラムの実行結果や実行時情報(型情報、プロファイリング情報、テストケース実行結果、VMイメージ…)を自由にアクセスでき、それをコンパイル時に利用する、ということがなされて行けば良いなあと。そうすれば、Staticalizerがしようとしていることとかもっといろんなこととかエレガントに実現できるでしょう。
未来の話であり、可能性でしかありませんが初夢でした。
