Ruby.NETの未来は不透明

標準MRIおよびRuby 1.9でそれにとって代わるものは別として、過去2年間は代替Rubyの実装で膨大な作業に追われ、JVMのJRuby(source)およびXRuby(source)、.NET向けのRuby.NET(source)およびIronRuby(source)そしてセルフホストであるVMであるRubinius(source)といった、その他のRubyの実装プロジェクトのホストがスタートした。
現在、とある統合が今起こっているようである。つまり、JRubyの勢いが増し、広く採用されているため、XRubyの開発は減速している。 また他の理由としては、 JavaでネイティブRuby機能を提供するJRuby拡張との非互換性があげられる(例：OpenSSL、Oniguruma regular expression engineなど)。

Ruby.NETを運営しているWayne Kelly博士は、Ruby.NETをIronRubyと対比して個人的な決定に達したようである。それについてRuby.NETメーリングリストで発表している内容は以下の通りである(source)。

先週のLang.NET Symposiumで、Ruby.NETプロジェクトの業績について発表し、IronRubyプ ロジェクトの進行状況およびDLR(その他にCharles Nutter氏発表のよるJRubyプロジェクト)の内部作業について詳細を聞く機会があった。 DLRは確実に定着し、Microsoftプラットフォームのますます重要な部分になりつつあるという結論に至った。また、質的生産のパフォーマンスを獲 得するには、Ruby.NETはDLRに相当するものを新たに考案(または採用)する必要があると強く思う。こんにち、プロジェクトを開始しているのであるならば、DLRを使用しない訳はないであろう。当初、Ruby.NETパーサーおよびスキャナーを内蔵し、DLRを利用することによりRuby.NET がIronRubyプロジェクトで良いスタートを切った一方、IronRubyが.NET プラットフォーム上でRubyの質的生産を実現する成功する可能性が高いと信じている。最終的に、2つの別々のRubyを.NETに実装する必要はないと 思う。そこで、結局Ruby.NETが実装の対象から外れるならば、その目的の追求にデベロッパが努力しているのを実りなく無駄にすべきではない。

Dynamic Language Runtime (DLR)(ブログ・英語)は、(動的)言語ランタイムの作成を促進するライブラリーである。例えば、デベロッパがMS ILインストラクションを直接作成することから守る。その代わりに、デベロッパがDLRツリー(ブログ・英語)を作成し、それをDLRがMS ILに変換する。

言語実装者にとっての作業の多くが省かれるので、このアプローチは近年注目を集めている。Ruby In Steelチーム(サイト・英語)のDermot Hogan氏が、Antlrツリー文法からDLRツリーの生成(source)について説明する。

Antlrで常にぶつかる問題がASTが存在するということである。次はどうしたらよいのか。Antlrで単純な文法を得ることは簡単であるが、CLR コードは単純ではないと発しているそれで実際に何かするには奇跡が起きる必要がある。 しかしツリー文法を介してAntlr ASTをDLRに結びつけることは、取るに足らない操作である。上記のコード参照。DLRの「アダプター」クラスを記述する。

Kelly博士のメッセージに対する反応には、IronRubyが.NETプラットフォーム上で唯一実行可能なRubyであるかのようだという事実に焦点を当てているものもある。例えば、 JRuby TeamのOla Bini氏はこう語る(source)。

こういったニュースは大嫌いだ。いろいろな意味で、手強い競争相手がいることはすべての人にとっての生態系を改善するようなことである。IronRubyは その分野で唯一のプレーヤーになるであろう。(Ted Neward氏やDavid Peterson氏のような)他の人びとがRuby.NETを選ばなければの話であるが。誰かがしてくれることを願う。.NETの世界はそのためには十分 良い。 極めて重要な質問は、IronRubyについてJohn Lam氏を信頼してよいかどうかではない。質問は、Microsoftが正しいことをしてくれると信用するかどうかである。信用するか。

これは、重要な点に言及している。というのは、Ruby.NETがOpen Sourceプロジェクトであり、1人のデベロッパが離脱することは、プロジェクトの中止ではなく、他のデベロッパたちがそれを引き継ぎ、引き続き開発を行うからである。

その一方、IronRubyチームのJohn Lam氏は以下のように述べている(source)。

Wayne氏に心から歓迎の意を表し、Open Sourceプロジェクト(source)に参加してIronRubyの 業務に携わってくれる方を招いている。Microsoft Researchは、Ruby.netの開発のため一部資金を提供してくださり、Wayne氏が、Gardens Point Parser Generator(source)の製造にあたり成し遂げた偉大な業績のおかげで、パーサーはIronRubyで持続している。[..]CLRに実装することは、.NET communityにとって意味があること。Rubyは単に言語だけによって定義されてはいない。それを実行するプログラムによって定義されている。このプロジェクトで最も難しい部分は、言語を正し く理解することではなく(それは確かに簡単なことではないが)、確実にIronRubyがRubyプログラムを実行させるようにすることである。そして、この頃Railsを嫌っている人たちが言っていることに関わらず、Railsは重要なプログラムである。

これは、John氏がIronRubyの現在の開発戦略について述べた以前のポストでサポートされている。(source)。

最後に、1.0への着手方法について話した。われわれは目標主導型の開発プロセスに転換しようとしているところだ。次の目標は、gem install hoeを作動させることである。Rakefileにはギャップと呼ばれるタスクが含まれており、set_trace_procインタープリターフックを介 してターゲットアプリケーションに対するギャップ分析を行うことを可能にする。

これは、Kelly博士の目標であるRailsのサポートと同じようである(source)。

依然としてまだ終わっていない作業があるような気がする。Railsを.NETで実行するという目標に身を定めたが、未だそれは達成できていない。経験からIronRubyをその地点まで持っていくことができれば、少なくとも手助けしたことからくる自己満足で、その作業が完了するのを待つのであろう。

注：Railsが.NETデベロッパにとっていかに重要であろうとも、Rubyの大部分、特にメタプログラミング機能を実行するのはコードベースである。IronRuby上で重要なRailsのアプリケーションが正常に作動していることは、Rubyの機能の大部分が適切に実装されていることを意味する。Rubiniusプロジェクトで定義された実行可能なRuby仕様を実行しているIronRubyプロジェクト(source)と組み合わされているので、客観的にIronRubyの互換性を定義することが可能である。

原文はこちらです：http://www.infoq.com/news/2008/02/ruby-dot-net-future-uncertain