NewsInsight

新バージョンで何が変わるのか、Rubyはどこへ向かうのか

まつもと×笹田、Ruby 1.9を語る

2007/12/25

　「そういえばあのretryの話、どう思う？」、「誰も使ってないから害悪が多いっていう話は説得力ありますよね」、「じゃあなくすか……、うん、なくしといて」、「あ、決まっちゃった（笑）」――。

　まつもとゆきひろと、笹田耕一。いま、世界が注目するプログラミング言語「Ruby」の生みの親と、開発コアメンバーの2人は、こともなげにRubyの仕様を記者の目の前で変更してしまった。Rubyの開発はどのように行われ、どこへ向かおうとしているのか。現行のバージョン1.8系から大きく様変わりする次期開発版「Ruby 1.9」のリリースを12月25日に控えた2人に、師走の秋葉原で話を聞いた（文中、敬称略）。

Rubyの仕様は密室で決まる!?

　冒頭に紹介した2人の会話は、「retry」というRubyの文法の2種類ある使い方のうち、これまでほとんど使われた形跡がない方を文法仕様から取り除くかどうか、という話だ。すでに事前に判断材料がそろっていたとはいえ、事実上2人だけの話し合いで決まってしまった。

――こんな風に言語に新しい仕様を加えたり、取り除いたりというのは日常茶飯事なのですか？

まつもと　最近あまり仕様を勝手に変更すると「ぎゃっ」という人が増えたので、だいぶ減りましたけどね。

――仕様変更の議論はメーリングリストではなく、オフラインの密室状態で行われることも？

まつもと　物事は密室で決まることになってるんです（笑） メーリングリストでの議論を踏まえて、だいたい1人とか2人で決めちゃいますね。

笹田　全部オープンな場で関係者全員で議論していたら収拾が付かなくなるってこともありますよね。まつもとさんを説得してエイヤッで決めてしまうことも多いです。

まつもと　特に外国人の方々は議論が見えないことが多くて不満もあるかもしれませんけどね。

笹田　例えばRuby 1.9では文字列処理の方法が大きく変わるんですが、そのとき文字コードについてさんざん議論しましたけど、それは日本人開発者の間だけでしたよね。

まつもと　いやいや、日本語のほうが多かったけど、英語で議論している人はいたよ。

――Java VM上のRuby実装である「JRuby」の開発者の1人、チャールズ・ナッターが、日本語の情報が読めないためにRuby開発コミュニティで何が起こっているのか分からないと不平を述べていましたね。

笹田　うーん、かつて、Rubyの開発者メーリングリストのサマリーを定期的に有志が英訳していたんですけど、あまり反響がなかったんですよね。2005年か2006年頃まで続けていました。

――むしろ早すぎたのではないですか？

笹田　そうかもしれません。中断した理由はマンパワーが足りなかったということなので、もし、「詳しい技術のことは分からないけどRubyに貢献したい」という人がいたら、ぜひボランティアで英訳をやってもらえるとうれしいですね。

40人のコミッターのうち30人弱が日本人

　インタビュー中にも笹田は、思い出しように次々に細かな変更リクエストをまつもとに対して出した。例えば、GC（ガーベージコレクタ）の並列化のアイデアについて話しているとき、笹田はおもむろに「gc.cのグローバル変数をやめて構造体で1つにまとめるとかしませんか」と切り出し、まつもとは鷹揚に「それは反対しません」と対応する場面があった。「ではやっておきます」という笹田のひと言で話が片付くというスピード感だ。

　まつもとは島根県をベースに東京と島根を往復する生活だが、その際の拠点の1つは東京・秋葉原にほど近い末広町にある。一方の笹田は現在、秋葉原駅前のビルが勤務先だ。

笹田　Rubyの開発をやっていて良かったと思うのは、やっぱり開発者のまつもとさんが日本人だったことですよね。Perlの作者であるラリー・ウォールに対して「Perlのここは良くない」とは言いづらいですし、英語では議論しづらいし（笑）

まつもと　ぼくには言いやすいかもしれないよね（笑）

笹田　こうして気軽に会うことができますしね。

――おふたりは普段はネットでもよく会話されてるんですか？

まつもと　うーん、会ったときは延々と話してますけどね。

笹田　Rubyの日本人コア開発メンバーはIRCに常駐してる方がいるので、私はIRCを使いますね。バグの報告があったときにIRCで議論して解決することが多いんです。そこで開発が回ってる部分はあります。

まつもと　ぼくはIRCはしないんですよ。時間がなくなっちゃうから（笑）

笹田　まつもとさんはエッジの部分を開拓していくことに専念してますね。

――まつもとさんはバグ修正など細かなことを自分でやりたくないのでは？

まつもと　いや、やりたいんだけど、ぼくがやるといつまでも終わらないんで、「まつもとに任せてちゃいけない」って感じで、後ろでサポートして直してくれる人たちがいるんです。

笹田　まつもとさんのコミットがあったときに、「あ、またまつもとさんがバグ入れてるよ」ということが、よくあります（笑）

まつもと　ぼくがゴリゴリ穴を掘るんだけど、後ろで「あ、危ない、危ない」って支えてくれる人がいるんですよ。見守られています。ありがたいことです（笑）

――現在、Rubyのコミッター（ソースコードの変更権を持つ開発者）は何人ぐらいいるのですか？

まつもと　40人ぐらいですね。そのうち30人弱が日本人。アメリカを除くとドイツに数人いたかな。ただ、40人いるといっても2、3回コミット（オリジナルのソースコードの変更）をして、それきり見かけないという人もいます。

笹田　ライブラリをコミットするためにコミッターになって、そのライブラリが安定したらもうコミットしないという人とかね。

まつもと　そういう意味ではRuby全体を見ているコミッターは5〜6人でしょうか。

――Linuxカーネルの開発者だと企業や研究所に属する人も多いですが、Rubyはいかがですか？

まつもと　Rubyの場合、私のところ（NaCl）を除くと、少なくとも企業を看板にしている人はいませんね。

――40人のコミッターは平等な立場ではないのですよね。まつもとさんが頂点に？

笹田　明らかなバグの修正であれば、みんな勝手にコミットしますけど、仕様に関わるようなところは、まつもとさんにお伺いを立ててからということになっています。だから私が入院してもどうにでもなると思いますけど、まつもとさんが入院したらRubyの開発は止まるでしょうね……、いや、仕様を変える人がいなくなるのでRubyの仕様が安定するメリットがあるかもしれませんが（笑）

Ruby 1.9は“ブリーディング・エッジ”の開発版

――Ruby 1.9について教えてください。1.9系の初めての正式版が12月25日に出る、ということでよろしかったですよね（編集部注：12月25日の深夜、Ruby 1.9.0正式版がリリースされた）。

まつもと　何かは出ます。

――実際は動いているコードがあるので、いまでも出せるといえば出せますよね。

まつもと　いまのままでも（笑）

笹田　いや、ちょっといまのままでは出せませんね。いろいろとバグ報告をいただいているのが収まっていないので……。

まつもと　まあ、バグはしょうがないよ。

笹田　どこまで互換性を考えるかですけどね。Rubyから見たら内部インターフェイスは変わらないかもしれないけど、まだC言語レベルで変わる可能性が残っていて……。

まつもと　その辺はいいんじゃないの？ 安定版のRuby 1.8だとまずいけどさ。

笹田　互換性とか安定性の話で言うと、Ruby 1.8の立ち位置ってRailsが出てきてだいぶ変わりましたよね。以前は良くも悪くも、まつもとさん個人のプロジェクトという側面が大きかったじゃないですか。それがいまや「安定しなければならない」という周囲からのプレッシャーのようなものがありますよね。

まつもと　うん、だからそういうのを全部押し付けるために1.8系を残しているわけで、1.9では好きにさせてと（笑）

――安定させなくても大丈夫なんですか？

まつもと　もちろん気は使っていますよ。でも、1.8に関してバイナリ互換性がなくなったらまずいと思うんだけど、1.9はいいんじゃないかな、という判断です。少なくとも1.8と1.9の開発が並行して動いている間は。

笹田　1.8は安定してきていますよね。いまはリリースマネージャも2人いるし。

――安定性を求めるなら1.9の新しい仕様は使わず、安定版の1.8を使ってくださいということですね。

まつもと　Railsも1.9対応になっていないですしね。

笹田　だけど、たぶん世の中の人は1.9にも1.8との互換性や安定性を求めていますよ。例えばJavaのVMでサン・マイクロシステムズが「次バージョンでバイナリ互換性はなくなります」なんてことを言ったら大ブーイングですよ。

――これは原稿にするとまずいのですよね……。

まつもと　いえいえ、逆にこれをちゃんと伝えていただきたいんです。1.9は安定版じゃなくて開発版です。“ブリーディング・エッジ”（Bleeding Edge）といって血がどばどば出ている状態のものです。そのために1.8系を用意しているということです。1.9の荒削りな部分が丸くなるには年単位で時間がかかると思うんです。そのときまでは1.8が運用されていると思います。もし何かの事情で1.9をエンタープライズで使いたいということであれば、自己責任でやっていただくしかない。

――でも、あまりエッジなことをやっていると、1.8系と互換性のあるJRubyがマスマーケットを獲って、Ruby 1.9とかい離していく可能性もあるんじゃないですか。

まつもと　ええ、Ruby 2.0が1.x系をサポートするJRubyと別物になる可能性はありますよね。

Rubyアソシエーション設立でRubyのサポート体制を強化

笹田　例えばJBossのバックにはレッドハットがいて、サポートがあります。Rubyにそれがあるかというと、ありません。まつもとさんの所属するNaCl（ネットワーク応用通信研究所）は、Ruby関連のサポートを提供しているとはいえ、基本的にはまつもとさんを雇っていること以外のコミットメントは、あまりしていませんよね。そういう意味で、ほかのエンタープライズアプリケーションとは違います。

　エンタープライズ向けの開発・サポートを期待する方々がいるのは分かっていますけど、RubyをJBossのようなものと同じ土俵で考えると違います。Rubyでも、そういう体制ができればいいのかもしれませんけどね。

まつもと　そういう受け皿としてRubyアソシエーションを考えてはいますけど、いまのところ1人雇ったら予算が全部吹っ飛んじゃうので、まだ難しいですね。

笹田　あ、そういう計画があるんですか？

まつもと　そのために法人格を取ったんだしね。法人格が必要なことは、予算の範囲内で何でもやりますよ。Rubyに対する投資や寄付についても、準備が整ったら始めたいですね。すでに誰もが名前を知っていてグローバルに事業を展開している企業からもアプローチがあったりするんですよ。

笹田　その寄付は安定版の1.8に対してのものになるんですか、開発版の1.9に対してのものになるんですか？

まつもと　企業ユーザーにしてみれば、1.8がより安定することもうれしいでしょうし、1.9がより早くエンタープライズレベルに到達することもうれしいでしょうから、どっちに投資していただけるかは企業次第でしょうね。でも、1.8基金とか1.9基金と分けて寄付に紐を付けるのかどうかは、まだ決まってません。できれば使い道はRubyアソシエーションに一任して欲しいですけどね。

――Rubyアソシエーションでは検定試験も始めていますが、ほかに何か具体的な案は？

まつもと　まだ理事長としての私のアイデアの段階ですけど、Ruby関連の開発プロジェクトを公募して、少額の助成金を出す「マイクログラント」を考えています。Rubyそのものでも、Ruby on Railsでも、ともかくRubyに関連したことであれば対象にします。数十万円という額ですけど、それでもプロジェクトをやりたいという人がいるようであれば、お金を出したいですね。人数的に厳しいかもしれませんけど、選ばれたプロジェクトのメンバーには、導き手となるメンターも付けられればとも考えています。

笹田　私、メンターやりたいです。

Ruby 1.9の最大の特徴は仮想マシンの採用

――Ruby 1.9と1.8の違いについて教えてください。

まつもと　最大の違いは笹田くんが書いたコードが入っていることです。1.8は、ぼくがこつこつ作ってきたものの延長で、非常に素朴な実装になっています。内部的には抽象構文木（AST：Abstract Syntax Tree）というものを構成して、そのツリー構造をたどりながら処理を実行しています。この処理を担当する「eval.c」という1万数千行のコードを全部取っ払って、1.9では笹田君が書いた「YARV」という仮想マシン（VM）のコードを入れました。

笹田　クルマにたとえれば、エンジンが入れ替わったようなイメージでしょうか。

まつもと　そうだね、重量比的には大きな割合ではないけど、決定的な違いです。ランタイムやライブラリはそのままです。1.9でも、先ほど言ったASTは作るんですけど、それをバイトコード――実際にはワードコードですけど――という数字の列に変換して、それを実行する形になります。要するに1段階、ステップが増えています。

笹田　JavaのVMと同じで、あの構造に追い付いたということです。

――コンパイルというか変換のオーバーヘッドというのはないのですか？

笹田　もちろん、あります。ありますが、起動時に100分の何秒か遅くなるという程度です。

まつもと　普通のプログラムであれば、読み込んで1回だけコンパイルしてASTを作り、1回だけバイトコードに変換して実行するので影響は小さいんです。

笹田　プログラムが10万行もあればコンパイルに時間がかかると思うんですが、Rubyでそこまで大規模なものは、あまりないですよね。

　ただ、例えばRailsをCGIで使うとなると、ちょっと問題になるかなという気はしているんですけど……。その辺はプリコンパイルみたいな処理を考えています。

――プリコンパイルしたバイナリコードをはき出すということですか？

笹田　ええ、今年の12月に出すバージョンには入れていませんが、そういうことを考えています。

まつもと　すでに道具立てはそろっていますから、やればできるんですけどね。バイトコードを出したいという人は結構いるんですけど、どのぐらい意味のあることなのか、個人的にはちょっと分かりません。

笹田　少なくともわれわれの興味ではないです。

VM化によるメリット

――なるほど。それで、VM採用によるメリットは？

笹田　これまでできなかった高速化や最適化ができることです。

まつもと　ASTのツリー構造をたどるのは、意外に重たい処理だったんです。ポインタを動かして次のオブジェクトを取り出す、という処理です。このポインタの操作は軽いと思っていたんですけど、結構重たくて……。

笹田　いまのプロセッサアーキテクチャだと、アドレスが離れてるとキャッシュに当たらないんですよね。それでポインタを動かすとキャッシュミスが起こって、メモリアクセスに余計にサイクルかかっちゃう。

まつもと　VMではバイトコードを順に読み出して実行するので、次の命令を実行するのは配列を1つインクリメントするだけとシンプルなんですよ。

笹田　VM化によって、いままでできなかった最適化ができるようになります。ASTの場合、この木とこの木を入れ替える、ということが難しかったんですけど、バイトコードのようにシリアルに並んでいる配列をちょこちょこいじるというのは結構簡単にできるんです。

　例外処理の方法も1.9では変更して速くなっています。1.9ではバイトコードにコンパイルする時に例外処理の飛び先アドレスを書いた表を用意しておくんですね。1.8では、そこをダイナミックにやっていたので余計な処理が発生していた。1.9では例外が発生した時点で初めて処理を行います。これは1.8に比べると少し重たい処理なんですけど、例外処理が発生するのは文字通り例外的なので、例外が起こったときにだけ処理しましょうという発想です。これはVM化によって可能になったことの一例です。これもJavaと同じようにしたということですけど。

　バイトコードをいかに速く動かすかというのは、長らく研究されていて論文の蓄積もあります。そういうアイデアを実装して入れていくことで、だいぶ速くなりました。

――それはJava VMの研究開発からも影響を受けているんですか？

笹田　ええ、ただ、Java VMの場合は、ものすごい最適化をしているんですね。例えばx86のこのプロセッサでは、こんなことができる、というレベルで最適化をしています。ものすごく速いですよね。

まつもと　YARVでは、まだハードウェア依存の最適化は手を出してないんだよね。

笹田　ええ、私1人だけで開発していたので、x86で最適化するとほかのアーキテクチャのマシンで動かないとか、ほかのマシンで遅いままになってしまいます。それが嫌だったので、まずはC言語のレベルでどこまで速くできるかをやってきました。それも、とりあえず一段落したので、次はx86用かなと思っていますけど。

まつもと　えっ、そうなの!?

笹田　JavaだとJITコンパイラとか、Hotspotとか高速化技術がいろいろとありますよね。そういうレベルのことです。あるいは、「LLVM」（Low Level VM）というオープンソースのソフトウェアがあるんですけど、このLLVM向けに最適化するという手もあります。YARVのバイトコードをLLVM向けにコンパイルすると、ハードウェア依存の部分はLLVMのほうでうまく最適化してくれます。新たに一層加えて最適化を丸投げしちゃうというアイデアです。

――最適化という意味では、まだまだできる？

笹田　まだやってないことはたくさんあります。

――人手やお金があればできるという感じですか？

まつもと　いや、むしろ時間でしょうか。いま以上に人が集まらないんですよ。

笹田　私は人が集まればやってほしいなと思っているんですけどね。絶対全部できないじゃないですか。まつもとさんのように全部自分でやりたいというのも理解できますけど。

――まつもとさんは、あまり下の方には興味がなかったのではないですか？ 低レベルな層でキャッシュラインの最適化を考えるスピード狂の人がいたり、いろいろな層の人がいて、ちょうどいいのでは？ 1人じゃ無理ですよね。

まつもと　残念ながら、それは認めましょう（笑）。本当は全部自分でやりたいタイプなんですけど、最近は講演も忙しかったりして……。1999年にはコードネーム「Rite」という名前でRubyもVM化するぞと宣言したんですけど、5年以上ほったらかしにしてあったんですね。そんな自分に対する罰としてVM化の部分は笹田くんに譲りました（笑）

　うーん、でも、構文木をたどる方式としては、やれることはやってるんですどね。小手先でやれることは限界までやってます。

笹田　いや、もうちょっとやれると思いますよ。

まつもと　えーっ、そうなの？ ショボーン（笑）

――ところで、おふたりで仕様や最適化のアイデアについてお話しをされていると、プロ棋士が碁盤なしに頭の中だけで将棋を指している姿を思い出します。どことどこを変更すると、どういう影響が出てということを考えたり、2人で話したりするとき、PCや実際のソースコードは不要なものですか？ とすると、例えばシャワーを浴びているようなときにも、Rubyのことを考えている？

まつもと　ええ、それがいちばん楽しい時間です。さっきも新幹線の中で仕様を考えていました。

笹田　私もYARVの実装を始めたときは寝ても覚めても実装方法、高速化手法を考えていました。電車での待ち時間など、暇つぶしの必要がなかったくらい。

まつもと　寝床に入ってしばらくしてから、「はっ、あのバグの原因はあそこにあった！」とひらめくことなんかもあります。それでPCの前に座ってコードを見ると、なんと、すでに直っていてビックリ！ って、それは単に自分が直したのを忘れてただけなんですけど（笑） 最近は、いろいろ手書きでメモを取るようにしていますね。

普通のプログラムはRuby 1.9で1.5倍程度に高速に

――Ruby 1.9では1.8に比べて、どのぐらい速くなるのでしょうか？

笹田　Cで書かれたライブラリが速くなるわけではないので、例えば正規表現を使ってがんがん検索するような処理だとYARVにしても、残念ながら速くなりません。

まつもと　速くなるのはRubyの普通の処理です。例えば変数の代入とかループを回したりという処理が速くなっているので、そこがボトルネックになっているようなものは速くなりますね。フィボナッチ数列の計算とか（笑）

笹田　パズルとか、文字列処理みたいなものが少ないプログラムは2倍くらい速くなるんじゃないかと思います。

――高速になれば適用範囲も広がるんでしょうか。

笹田　例えば科学技術計算に使えるかといえば、まだそこまで速くないですけど、そのプロトタイピングぐらいには使えるかもしれません。少なくともフィボナッチの結果を見て「Ruby遅い」といっている人たちには、その理由はなくなりましたよと言えるぐらいにはなっています。

まつもと　ああ、それは結構大きい。Great Language Shootoutっていうプログラミング言語のベンチマークのサイトがあるんですけど、その成績で言語を決めるという人って結構無視できない数いるんです。

　ぼくらは「言語の一部の性能しか計測しないマイクロベンチマークなんて意味ないよ」と内心は思ってるんですよ。でも、そんなベンチマークは役に立たないよと言って回るよりは、そのベンチマークで好成績が出るように言語の性能を上げたほうが早い。実際、Shootout系のベンチマークは1.9で速くなるので、Shootoutをマーケティングに逆利用できそうです。

笹田　私の感覚では普通のプログラムで1.5倍ぐらい速くなるという印象ですね。Rubyは遅いなと感覚的に感じていた方なら、改善される可能性はあります。I/Oやネットワークがボトルネックだと違いますけどね。まだI/O関連の処理では高速化や最適化でできることがたくさんあるので、これからも速くしていこうと思っていますけど。

作った本人も知らなかったYARV採用の顛末

――笹田さんが書かれたYARVがRuby 1.9に採用された経緯について、もう少し教えてください。Ruby処理系向けの高速なVMを作るというプロジェクトとして「Yet Another Ruby VM」（YARV）という名前で作り始めたのはいつ頃ですか？

笹田　2004年の1月頃に学生で暇だったので趣味で始めました。それから4年経って、やっと実を結んだという感じですね。昔はアドオンみたいな感じだったんですけどね。

――ほかにもRuby向けのVMは、いろいろあったし、いまでもあるんですよね。

まつもと　ええ、ほかにもCardinalとかRubiniusとか。

――まつもとさんは、いつ頃、自分のコードの代わりに、次期バージョンにYARVを採用しようと思ったんですか？

まつもと　YARVが未踏に通ったときには、もう決めてました。

笹田　ええっ！

まつもと　最初の未踏が終わった頃には、これはもう物になると思っていました。

笹田　ああ、そうだったんですか！ 知らなかった……。私が認識したのは2回目の未踏の成果発表会の日です。発表を盛り上げるために「YARVをRubyに入れていいですか」と聞いたんですね。そうしたら気楽に「うんいいよ」と答えていただいて。

まつもと　ぼくの中では前から決めてたからね（笑） 初めてYARVのコードを入れてRubyが動いたときは、ちょっと感動しましたよ。

1.9で大きく変わる文字列処理

――YARV採用のほかにRuby 1.9の大きな変更点は？

まつもと　多言語化です。まず前提として、Rubyのポリシーに「内部コードを持たない」というのがあるんですね。内部に特定の文字コードを採用しない、ということです。

――Unicodeでは駄目なんですか？

まつもと　個々のアプリケーションはそれでいいのですが、プログラミング言語の場合、特定のエンコーディングを選択してしまうと、すべてがそれを選択せざるを得なくなってしまうんです。これは2つの理由で好ましくありません。

　歴史上、日本には文字コードっていっぱいありますよね、シフトJIS、EUC、JIS、Unicodeと。そういう混在環境での処理方法は2つあります。1つは、どれかの文字コードに統一して後で変換して戻す方法です。しかし、これだと既存のドキュメントで変換が必須になって無駄ですし、2度の変換で文字化けが発生するという、いわゆるラウンドトリップが出来ないケースが出てきます。ファイルから読んで戻すだけなら同一の変換テーブルを使うのでいいのですが、どこかからデータを読んで書き出すとなると、何が起こるか分からない。と、考えると、諸悪の根源は変換です。だから、できるだけ変換をやりたくないと、1.8の時代から内部コードを持たないというポリシーでやってきたんです。

　もう1つの理由はオープンエンドということです。例えば日本だと、研究者レベルではUnicodeではない文字コードを使っている人もいます。今昔文字鏡やGTコードなどです。そうしたものも平等に扱えるというオープンエンドというのも内部コードを持たないメリットなんです。

　まあ、ただ、文字コードは外部の環境の影響も大きくて……。例えばGUIライブラリがUnicodeしか受け付けないとかだと、結局渡す前に変換する必要がありますよね。実はそういうケースが増えていて、ちょっと苦労が報われない感じなんですけど。

笹田　文字列といったら、ちゃんと文字単位で扱えないと嫌だという声が強かったんですよ。UTF-8だったら、lengthメソッドで返ってくる値はバイト数じゃなくて文字の長さであってほしいと。

まつもと　そういうわけで、1.9では文字単位で操作できるようになります。“あいうえお”が5文字です。

――現状の1.8だとどうやって数えるんですか？

まつもと　正規表現を使って文字単位に切って数えます。文字単位で文字列を扱うということは、そもそも正規表現を使うだろうという考え方です。個人的には正規表現でほとんど用は足りると思うんですけど、要望が多かったんです。

笹田　Rubyの場合、lengthメソッドで文字列の長さが欲しい人もいるし、バイト長が欲しい人もいる。それがなかなか解決できなかったんですよね。

まつもと　例えばJavaの場合、サロゲートペアを使ったUTF-16のエンコーディングで正しい文字数を返すAPIというのが、通常の文字列の長さを返すAPIとは別に用意されています。文字列の長さを返す似たようなAPIが2つあるというのは、シンプルさを重視するRubyとしてはやりたくない。

　それで、1.9からは文字列1つずつにエンコーディング情報を持たせるようにしたんです。「この文字列はUTF-8で書いてある」というようにです。

――Javaに比べてRubyではシンプルさを優先したということでしょうか。

まつもと　私は自分ではJavaは書かないんですが、読んでるだけで頭が混乱することがあります。文字列の扱いでいうと、input streamの上にstringbufferを積み重ねて……って、覚えてられない（笑）

笹田　Rubyでは文字列に文字列を追加することが簡単にできますけど、Javaでは可変長のstringbufferにいったん文字列を入れて、作業が終わったら、そこで確定して固定長のstringに代入するという処理が一般的ですよね。string型とstringbuffer型の2つがあって書き方を覚えなきゃいけない。

　もちろん、性能を考えるとそのほうが有利な局面もありますけど、プログラマの書きやすさを考えると、stringという型は1つのほうがいいですよね。

Rubyのシンプルさを支える大クラス主義

――Ruby 1.9の新機能にFiber（ファイバ）が入ると聞きました。

笹田　Fiber自体はあまり気にしていただかなくて結構です。FiberはGeneratorを実装するために使っています。JavaのイテレータのようなものをRubyで書くのは大変だったんですよね。

まつもと　Javaのイテレータでは、配列からオブジェクトを1つ取ってきて、そのオブジェクトにアクセスすると別の配列からオブジェクトを1つずつ取ってきて順に処理する、ということができるんですね。

　Rubyではブロックと呼ぶんですが、配列オブジェクト自体がメソッドを持っていて、メソッドの中で閉じているんですね。だからJavaのイテレータに似た処理をするには別のオブジェクトを作らないといけなくて面倒なんです。

　Rubyのブロックは「1つ取ってきて渡して処理して、また次に1つ取ってきて処理」というモデルで、シンプルで分かりやすいというメリットがあります。でも、2つ配列があって1つずつ取り出してきて処理するというのは、面倒だったんです。

笹田　言語によっては外部イテレータとか、カーソルオブジェクトといいますよね。そういうポインタみたいなものが以前はGeneratorというライブラリで提供されていました。それをもっと手軽に、軽量に行う仕組みが1.9でEnumeratorに導入されました。

まつもと　1.8にもEnumeratorとGeneratorという2つの似たようなライブラリがあったんですけど、それが1.9ではEnumeratorに統一され、組み込みになりました。ここら辺、ああ、Rubyはやっぱり“大クラス主義”だなって思いますね。

――大クラス主義とは？

笹田　似たような機能のものを大きなクラスにまとめるという方針です。たくさんあると覚えるのも大変だし、使い分けられないから、まとめちゃう。

　例えば「配列」といったとき、普通の言語ではpushで要素を加えたり、popで要素を取り出して配列の長さを縮めたりできませんよね。CやJavaの配列は固定長なので、できません。リスト構造を使うか、なければ自分で作ります。だけど、Rubyでは「似てるから1つにしちゃえ」という発想で配列がリスト構造のように振る舞い、伸び縮みします。

まつもと　Rubyでは、スタックとか、キューとか、そういうデータ構造も含めて配列の「Array」というクラスに全部突っ込んじゃってるんですよね。

笹田　だからデータ構造の授業をRubyでやると大変なんです。スタックはこういう風に作るんですよといって、ポインタが次の配列を指してって説明しますよね。でも、Rubyではそういうのは一切要らなくて、全部配列で済みます（笑）

今後は並列処理もテーマに

――今後、Rubyとは別にまったく新しくプロジェクトを始めるというお考えはないのですか？

まつもと　うーん、ぼくは物事を始めるのにモーメントが大きいタイプなんですよ。Rubyでもまだまだできることがあるしなぁ。

――笹田さんは？

笹田　Rubyの代替となるような言語は作ってみたいですね。Rubyにも良い仕様、悪い仕様ってありますよね。

まつもと　うん、あるね。

笹田　研究者なので、例えばいまだったら並列向けの仕様を最初から入れると、どうなるんだろうという技術的な興味があります。

まつもと　もともと笹田君は並列が専門の人だしね。

――笹田さんは以前、こんな話をされていましたよね。プログラミング言語の新しいパラダイムをピュアに取り込むと、現実のプログラマには受け入れられなくて、Rubyのように新規性と伝統的な言語のスタイルや発想をバランスよく取り入れたものが普及する。同じように、並列化というテーマでも、あまりピュアに最初から並列化を目指すのではなく、うまいバランスがあるのではないか、と。

笹田　ええ、だからRubyはRubyでバランスよく並列処理は取り込んでいけばいいと思います。ただ、言語レベルで変えたらどうなるかなっていうことにも興味があります。これは思考実験で終わるような気もしますけど。

まつもと　既存言語の並列版といえば、こんな例もあるよ。Satherって言語があるんですけどね、そのSatherの並列版としてpSatherというのがあるんです。パラレルSather。

笹田　そのpSatherって、うまく行ったんですか？

まつもと　いや、Sather自体がマイナーです（笑）

笹田　いや普及という意味ではなくて（笑）

まつもと　pSatherではparloopというforの並列版に相当する構文が増えています。forのようにループを回すのではなく、並列でドカンと走らせることができる。ほかにもpSatherにはアクターモデルを実現する文法が追加されていたりします。

笹田　そのへん、どんな実装がいいんでしょうね。

まつもと　分からない。でも、少なくとも、いまのRubyのインスタンス変数の持ち方だと、厳しい気がする。

笹田　いや実は、そこはあまり問題ではないんですよ。

まつもと　あっ、そうなの？

笹田　ただ、やるんだったら、文字列を全部変更不可にするぐらいの変更が必要ですね。でも、それをやっちゃうとプログラマには不自然だし、使いづらいでしょうから、むしろRubyのような普通のプログラム言語が中に閉じているものが並列に動くのがいいのかなという気がします。いまのRubyは大域的に何でも出来ちゃうので、それを狭めて並列化する、というイメージです。

――それはまつもとさんが楽天でやってらっしゃるFairyプロジェクトみたいなものでしょうか。

まつもと　あれは言語に手を入れるというよりも、システムを提供するタイプの並列ですね。並列というより分散システムです。グーグルのMapReduceとかGFSを意識しています。タスクを多数のマシンに振り分けるDSL（Domain Specific Language）を用意する形になるかもしれません。

――Rubyの並列版を作って「pRuby」を名乗れば晴れてP言語の仲間入りですよ。Perl、Python、PHP、pRuby（笑）

笹田　なるほど！

---

　今回、Ruby 1.9について教えてくださいと2人に取材を依頼し、秋葉原のカフェで1時間ほどお話しいただいた。ちょうどお昼どきだったので、取材を終えてから記者も食事をご一緒させていただくことになった。

　お昼の12時半ごろに入店して、店を出たのは実に夕方の4時過ぎ。あまりに長時間話し込んでしまい、まつもと氏は飛行機に乗り遅れてしまった。所々で2人の会話に割って入る私の質問に丁寧に答えていただきながらとはいえ、4時間にも渡って、まつもと氏と笹田氏は延々と技術論を続けた。Rubyについてばかりでなく、並列Rubyの可能性や、米アマゾンが取り組んでいる分散コンピューティングの論文の話、100年後のプログラミング環境の話、普段使っているPCやソフトウェアの話と話は弾んだ。

　プログラミング言語としての可能性を追い求め、知的探求心から開発に情熱を燃やす2人を見ていると、これこそ1990年代以降にフリーソフトウェアが大きな力を持つに至った原動力なのではないかという思いが強くなった。いまのままRubyに関わって食べて行ければそれでいいと笑う欲のないまつもと氏にしろ、実装してみたいアイデアやプランに溢れた笹田氏にしろ、現在急速に進んでいるRubyの受容に対して意外に恬淡としている印象を受ける。Rubyが普及し、結果として世の中に役立つことは喜ばしいにしても、もともとの動機は、むしろ知的好奇心。記者には、「それがぼくには楽しかったから」といったLinux開発者のリーナス・トーバルス氏の姿に、まつもと氏らが重なって見える。

　いつまでも楽しそうに議論している2人を見て記者は、こう思った。「これは、パズル好きの人が好きなだけパズルをやり続けている状況だ」。このパズルのたとえが妥当なら、Ruby 1.8とRuby 1.9の位置付けを整理すると、こうなる。パズルを構成するピース自体は固定されていて、もう後は少しずつ入れ替えたり、ピースを洗練させるだけの状況――、それがRuby 1.8系だ。Ruby 1.9系というのはパズルを構成するピースすら作り替えるようなもの。

　12月25日に正式リリースするRuby 1.9というのは当面、これからRubyを使ってみようというユーザーのためのものというよりは、知的好奇心から使ってみよう、中を覗いてみようという人たちのためのものだ。それは、自分たち同様のパズル好きのために、まつもと氏を中心とした開発メンバーらが用意したクリスマスプレゼントと言えるのかもしれない。

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）