Groovy-1.0-jsr6

先月の末にGroovy-1.0-jsrが公開されたみたい。なぜこのようなことを知っているのかというと、最近Groovyを調べているから。
Groovyは去年の3月ごろ一度チェックして良い感触を持っていたのだけれど、当時Groovyを使用して行う予定だった仕事がキャンセルになったことと、当時使用していたノートPCがクラッシュして成果物が失われてしまったこともあり、なんとなく疎遠になっていた。

ボクはもともとLispでプログラムを書くのが好みだったのだけれど、大規模プログラムをLispで書くのがかなりツライことを感じ、静的型とモジュール化機能に期待してOOPに移ってきた。ただC++では、メモリ管理が複雑であることにより(バグが出やすい上に)肝心の(本格的な)OOPが難しい、という問題がある。その上OSやミドルウェア層の標準APIが用意されていない、という問題もあり業務に利用するのには時期尚早と感じていたところに現れたのがJavaで、それ以降はJava一筋である。

Javaの静的型は大規模プログラムを作成するには必須の機能であり今後も主食として利用する予定ではあるのだけれど、その周辺を埋める細かなところでLisp的なパラダイムの必要性は感じていた。その流れからXMLに行ってみたものの、XMLそのものはプログラミングとは少し異なった立ち位置にある技術であるため、なかなかピッタリとした解が得られなかったのである。
この問題をGroovyのClosureが解決できそうなのである。この予感が正しければ現在開発中のRelaxer5での懸案事項であったDSLの実現手法の問題がクリアできる。

もちろんスクリプト言語の登場によってプログラミングにおけるXMLの価値がなくなるわけではない。テキスト処理はプログラミングにおいて永遠の課題であり、XMLはこの技術の基盤であり続ける。

つまるところ、Javaのような静的型コンパイラ言語とGroovyのような関数型的動的型スクリプト言語、そしてXMLの組合せがこれからのプログラミングパラダイムの基盤となるということである。
この3つの技術体系をどのようなバランスで体系化するのかというチャレンジには、わくわくするような面白さがある。

Relaxer5は、こういった新しい技術体系の一つの形を提案することが目的の一つである。さらに、上流と下流を繋ぐ"中流"モデリングの基盤とすることも目的となっており、色々な技術的な流れを1つのソルーションとして収斂させてみたいのである。構想が大きすぎて、いつどのような形で一般に公開できるレベルのものになるのか分からないのだけれど、ボクが個人的に遊ぶには格好の材料である。