【3/18〜】Amazon、VMwareが語る『クラウドの未来』        

【LL魂2007レポート：その4】

Java、.NETのすき間を埋めるLL言語

2007/08/08

　軽量プログラミング言語の恒例イベント、「Lightweight Language Spirit」（LL魂）。レポート第4弾は、JRubyやIronPythonなど、JavaVMや.NET環境にまで広がりを見せつつある処理系に注目したパネルセッション「VM魂」についてお伝えする。

PythonとJavaScriptでモジュールを共有するデモンストレーション

　セッションで取り上げられたのは、JRuby、Jython、Pnuts、Rhino、Groovy、IronPython、IronRuby。関係者や造詣が深いユーザーが、それぞれの視点から、これらの処理系を紹介した。

　マイクロソフトのアーキテクト・エバンジェリストの荒井省三氏は、Silverlight上でIronPythonとJScriptを使い分けるデモンストレーションを行った。IronPythonとJScriptは、それぞれ.NETフレームワーク上で実装されたPythonとJavaScriptの処理系で、ともにDLR（Dynamic Language Runtime）で動く。驚くのは、Python側で読み込んだモジュールを、JavaScript側でインスタンス化して利用できるということだ。

IronPythonのデモンストレーション。Silverlightで簡単な電卓を実装。デモでは、まずPython側でモジュールを読み込んだ。続いて左下のボタンで「jscript」を押し、対話シェルがJScriptに代わったところでJavaScriptを使ってロード済みのモジュールをインスタンス化してみせた

　DLR上では、すでにIronRubyとしてRubyの処理系も実装されているから（参考記事：マイクロソフト、Ruby言語インプリ「IronRuby」をリリース）、.NETフレームワークでは、C#やC++とともにRuby、Python、JavaScriptが利用できるばかりでなく、これらのLL言語間ではモジュールの共有も可能というわけだ。

　デモンストレーションのインパクトから、記者は思わず隣に座っていた知人のハッカーに「すごいね」と話しかけた。すると戻ってきたのは「でも、オブジェクトのマッピングは自明じゃないから、そうそううまく何でも共有できると思えませんね」という冷めた分析。ハッカーという人種は、意外に冷静な人たちだ。

　そもそも、ある1つのVM上に異言語を載せたところで、それらはパフォーマンスの点でネイティブの処理系にかなうことはない。確かに現在のところ、IronPythonはCで書かれたネイティブの処理系（通称CPython）よりも高速だというし、プロセッサの構成の仕方によってはJava VMの並列処理のメリットが享受できるJRubyが、ネイティブのRubyよりパフォーマンスがいいという可能性もあるという。しかし、一般的にいえばVMは言語ごとに設計するのがパフォーマンスの面から考えればベストだ。

Java開発者にも気軽さに気付いてほしい

パネルディスカッションの参加者。左から、モデレータの星暁雄氏（コモンズメディア）、Jython紹介者の西尾泰和氏（サイボウズ・ラボ）、Rhino紹介者の鈴木雄介氏（アークランプ）

　では、既存のVM上に実装されるLL言語の存在価値とは何か。「コンパイルしないことに価値がある」というのは、前出の荒井省三氏だ。「.NETでの開発は、コーディング、ビルド、テストというサイクルで、ちょっとした変更やテストでも手間がかかる。LL言語なら、その場ですぐに試せる」（荒井氏）という。

　Java VM上で動くPython処理系「Jython」について紹介したサイボウズ・ラボの西尾泰和氏も、「ライブラリをインポートして、ちょこちょこ書いたり変更して試せる。そうした気軽さに、Java開発者の方々にももっと気付いてほしい」と話した。「たとえて言えば、Javaは象のようなもの。素早く動けない。LL言語は小回りの利く斥候のようなもので、プロトタイピングに向きます」（西尾氏）。同じJava VM上で動くLL言語、「Pnuts」を開発した戸松豊和氏は、Java開発時のテストツールとして開発をスタートしたという。

パネルディスカッションの参加者。左から、JRuby紹介者の高井直人氏（recompile.net）、マイクロソフトの荒井省三氏、Pnuts開発者の戸松豊和氏

　現在のLL言語の祖先に当たるPerlやawkといったスクリプト言語は、もともと「グルー」（glue；糊）と呼ばれていた。これらの言語は、それを使って高度なプログラムを実装するというものではなく、既存の言語やツールを組み合わせるための糊のような存在だった。そう考えれば、Unix上で活用されていた、こうした“糊”が、汎用フレームワークのJava VMや.NETに採用されたのは自然な流れだ。例えばJavaとJRubyは互いに補完的な関係にある。

　Java VM上に実装されたJavaScript処理系である「Rhino」について紹介したアークランプの鈴木雄介氏は「バックエンドで多人数が関わる開発にはJavaが向き、1人でちょこちょこというのがLL言語」と、その相補的な関係を表現した。Rhinoを使うとサーバ側でもクライアント側でもJavaScriptで開発できることになるが、鈴木氏は「自分がサーバとクライアント、どっちのコードを書いてるのか分からなくなるのが問題です」と冗談か本気か分からないコメントで会場の笑いを取っていた。

IronRubyはRubyのコードを見て作ったのか？

　会場から1つ、興味深い質問が飛び出した。マイクロソフトは、IronRubyの実装に当たって、Rubyのソースコードを参照しているのか、という質問だ。良く知られているように、Rubyには言語仕様書というべきものが存在しない。このため、オリジナルのRubyとの互換性を確保するには、ソースコードを見るのが手っ取り早い。しかし、マイクロソフトはオープンソースの成果物から不用意にコードが自社製品に混入するという事態を防ぐために、開発者はオープンソースのコードに目を通さない、と言われている。

　マイクロソフトの荒井省三氏は、こうしたポリシーがマイクロソフト社内に存在するのかどうかついて、直接の言及は避けたが、同社でIronRubyの開発を担当しているジョン・ラム（John Lam）氏はRubyのソースコードを読んでも良いということを、まつもと氏と確認したという。そしてラム氏がRubyの仕様書を書き、それに基づいてマイクロソフト社内の開発チームはIronRubyを実装したのだという。

（＠IT 西村賢）

情報をお寄せください：