はじめに
MicrosoftのIronRubyプロジェクトは、強力で楽しい動的言語をWindowsプラットフォームにもたらします。Rubyプログラミング言語は、現代的なオブジェクト指向のスクリプト言語であり、PerlやSmalltalkなどの言語からヒントを得た構文を備えています。この言語を考案したのは、まつもとゆきひろ氏（"Matz"）です。まつもと氏は、「Perlよりも強力で、Pythonよりもオブジェクト指向の強い」言語が欲しかったと述べています（詳細は、まつもとゆきひろ氏のインタビュー記事を参照）。Rubyは自然な感じがするように設計されています。まつもと氏はこれを「驚き最小の原則（principle of least surprise）」と呼んでいます。Rubyのバージョン1.0は1996年にリリースされました。
数年間、Rubyは当初の設計目的だった処理（最小限の労力でデータと環境を操作する）に秀でた、ほとんど無名のスクリプト言語として存在していました。数年前、私はよくやる管理作業を自動化するために、何かバッチファイルに代わるものを求めてRubyをいじり始めました。
Rubyの人気に火がつき始めたのは、イリノイ州シカゴの37signalsという小さなソフトウェア会社がRailsという名前のWebアプリケーションフレームワークをリリースしてからです。この新しいフレームワークでは、Model-View-Controller（MVC）やActiveRecordなどの実証済みのパターンが、「規約は設定に勝る（convention over configuration）」といった新しい概念と結合されました。その結果できあがったのが、コードをほとんど書かずに多くの機能を実現するフレームワークです。
本稿は『CoDe Magazine』の2008年9月/10月号に掲載されたものです。許可を得てここに転載されています。
RubyCLRとIronRuby
2006年初旬に、John Lam氏はRubyと.NETの間の橋渡しの役割をするRubyCLRというプロジェクトを発表しました。RubyCLRによって、.NETプラットフォームの豊富な機能にRubyから直接アクセスすることや、RubyのオブジェクトをCLRに公開することもできるようになりました。これは非常に野心的なプロジェクトでしたが、.NET上にRubyを実装するという類のものではなく、あくまで両者の対話を可能にするものでした。コンピュータには依然としてRubyランタイムをインストールする必要がありました。
RubyCLRプロジェクトは、Rubyと.NETをうまく共存させる方法を理解するための大きな第一歩になりました。Johnの成果は注目を集めることとなり、2006年終わりに、彼は自らのブログでMicrosoftの新しいDynamic Language Runtime（DLR）チームに加わることを発表しました。Johnの発表のわずか数か月前に、Microsoftは.NET Framework上のPython言語の新しい実装である、IronPythonのバージョン1.0をリリースしました。Dynamic Language Runtimeの作業ではIronPythonの成果を取り入れ、.NET Frameworkの上にランタイムを構築して、はるかに少ない労力で動的言語を.NETに統合できるようにしています。
Johnのチームは、2007年のMIX ConferenceでIronRubyを発表しました。おそらくIronRubyプロジェクト自体の発表以上に驚きだったのは、これがMicrosoft初の真にオープンソースの.NET言語だったということでしょう。ソースコードが公開されるのはもちろんのこと、外部のコミュニティによる貢献も認められています。
IronRubyはまだ開発の途中にあります。通常は別のプロジェクト（例えば最近リリースされたSilverlight 2.0 Beta 2）との関連で、その動向をうかがい知ることができます。プロジェクトを追いかけている人々はソースツリーに追随し、メーリングリストに参加しています。
Rubyを習得する理由
私のお気に入りの本の1つ、『The Pragmatic Programmer: From Journeyman to Master』（Andrew Hunt/David Thomas共著、Addison-Wesley Professional）【邦訳：『達人プログラマー：システム開発の職人から名匠への道』（ピアソンエデュケーション）】では、毎年新しい言語を1つ習得するよう勧めています。私にとって自らの世界観を大きく変えた言語がRubyでした。
Rubyは、Smalltalk的な意味で完全なオブジェクト指向言語です。つまり、システムで操作するものは、数値などの直値を含めてすべてオブジェクトになります。新しいオブジェクトインスタンスを生成するときの雛型となるクラスでさえ、それ自体がシステム内のオブジェクトなのです。
Rubyは動的言語なので、型はほとんど重要でなくなることが分かるでしょう。メソッドがオブジェクトをパラメータとして受け取るときに、そのオブジェクトの型を指定する必要はありません。実際、コンパイラがないので、メソッドに渡したオブジェクトがそのメソッドの要件に適合していないことが、実行時までわからない場合もあります。
数年前の私と同じように、この概念に少し不安を感じる人がいるかもしれません。「実行時エラーが発生する前に、そうした問題をできるだけ早く発見できるようにコンパイラが存在するのではないでは？」と感じるのはもちろん正論で、コンパイラがあれば、より有益なフィードバックをより早く得ることができます。それでは、なぜコンパイラを捨ててまでRubyのような言語を使うべきなのでしょうか。
結局のところ、コンパイラは非常に誘惑的な形の束縛なのです。型の不適合を指摘するコンパイラの機能は、必然的に一種の型の厳密さをもたらします。メソッドを記述するときに、「ここのオブジェクトはfooとbarができなければならない」ことを示そうとして、IFooBarというインターフェイスを用意することがあります。これは要件を表すためのうまい解決策に見えます。しかし、IFooBarより前に作成された他人のクラス（特にフレームワークのクラス）を使いたいときには、役に立ちません。
まだIronRubyは本格的に利用できる状態ではありませんが、標準バージョンのRubyを使って体験してみることができます。これ以降の例を実行する場合は、Ruby Installer for Windowsをダウンロードしてください。
