Rubyの今後の進化の方向性とは？

開発コアメンバが語るRubyの今とこれから（後編）

2009/07/24

　Ruby開発コアメンバのまつもとゆきひろ氏、笹田耕一氏、yugui氏の3人に話を聞いた。対談の前編ではバージョン1.8系から1.9系へという大きなバージョンアップの話を中心に、RubyとRailsの関係やRuby開発コミュニティのあり方についてお話しいただいた。後編の話題は、Rubyに宿る設計思想や、今後のRubyの多様化や進化の方向性などだ。

LispとRubyの違い

＠IT　yuguiさんは子どもの頃からプログラミングを？

yugui　最初に触ったのはN88-BASICでした。父のお下がりで、一次方程式を解いたりしてましたね。

＠IT　それは中学生のとき？

yugui　えーと、小学生ですね。

まつもと　おぉー、ちょっと何だろう……、ぼくとのこの差は……（笑）

yugui　その後、FM-TOWNSのBASICでライフゲームを作ったりしてました。その後、Webがブレークした頃にはHTMLバリデータを書きたくて、それでいろいろ言語に手を出し始めて、VBをやって、Cをやって、C++をやって、PerlをやってRubyをやってという流れですね。当時XSLTがなかったので、コンテンツ管理をやるのに、バリッドなマークアップデータを変換する訂正処理系を作りたくて、そういうことを……。

＠IT　Perlで？

yugui　いやVBで。

まつもと　それをVBでやるんだ（笑）

yugui　VBが遅いし、ランタイムが大きいのがイヤになって、Cを覚えたんですよ。それから一時は証明にはまっていました。予備校で、大学でいう証明プロセスみたいなのを習ったので、それをある程度自動化できるなと思ったんです。いま思うと定理証明系の初歩的なやつなんですけど、それを書こうと思っていろいろと本を読んだりしました。定理証明系という言葉を見つけられれば良かったんですけど、試行錯誤で終わってしまいました。見つけてたらMLに行ってたかもしれませんね。

左から笹田耕一氏、yugui氏、まつもとゆきひろ氏

＠IT　定理証明系も処理系のジャンルなんですか？

まつもと　ええ、そういうソフトウェアの分野があるんです。ある記述があったときに、それが本当に正しいかどうかを証明するんですね。

＠IT　プログラムにバグがないことを実行前に証明する？

まつもと　そう、バグがないプログラム。そんなの書けるかよって泥臭いエンジニアのぼくなんかは思うわけですけど、それを一生懸命やってる人たちがいるんです。論文もいっぱい出ていて、最近はやりですね。フランスのCoq（コック）とか。数学系のものはフランスが多いですね、OCamlもフランスですし、MLの元祖はイギリスだけど、フランスで発展したし。

yugui　結局、代数系を書きやすいスクリプト言語としてRubyを選びました。代数系の学生でしたので、演算子オーバーロードができるのがうれしかったですね。群論のモデルをいろいろ作って実際に動かしてみたりするのは、演算子オーバーロードができないと話にならなくて。それで、その後にJavaを覚えたり、Schemeを覚えたり。

＠IT　先日の講演でyuguiさんは、「Rubyがバージョン2.0に向かって関数型っぽくなっていっている。だったら最初からLispでいいじゃないかという意見もある。私もまったくその通りだと思うと言わざるを得ない」、とおっしゃっていました。その辺どうですか？

yugui　久しぶりにCommon Lispを書いたら書きやすいんですよね。いいものですよね。

まつもと　うーん、Lispを悪いとは言わないですけど、書きにくいです。

拡張は語彙のみ、文法に求められるのは安定性

＠IT　これをまつもとさんに聞きたかったんですけど、去年、2008年の軽量言語イベント「LL Future」のパネルディスカッションのときに、ラリー・ウォールがPerl 6について「Embrace Perl, Expand Perl」といって、みなさん言語自体を拡張してくださいということを言ったんですね。それに対してまつもとさんは、あんまり良いアイデアだと思わないと発言しました。何でもかんでもユーザーにオープンにしてやらせるのは良くないっておっしゃったんです。

まつもと　そうですね。

＠IT　いつもまつもとさんは、Perlを作ったラリー・ウォールを尊敬していると言ってらっしゃるので、この正反対の主張をどう考えればいいのかなと思ったんです。

まつもと　うーん、彼のやってきたことや態度は尊敬してるんだけど、彼の技術的判断のすべてを支持するわけではありません。もし彼の技術的判断をすべて支持していたらRubyではなくPerlができていたわけで（笑）ぼくは、ぼく自身の経験からLispのマクロとかPerl 6のrulesみたいな、言語そのものの姿を消してしまうものは良くないと思っています。プログラミング言語って、思考の道具なので、ある程度安定した部分がないと、コミュニケーションの道具として使いづらいですよね。ぼくは日本語をしゃべってるつもりなんだけど、日本語に新しい文法がどんどん入って、例えばギャル語みたいになると、聞く人によっては全然意味が分からなくなる。そういうのはコミュニケーションの道具として不自由かな、と。プログラミング言語には変わらない部分があって、変わらない部分と変わる部分があるべきじゃないかなと思うんです。メソッドのように語彙に当たる部分は変わってもいいけど、文法に当たる部分はあまり変わらないほうがいい。根幹になる文法は思考の表現になります。語彙は、分からなければ辞書を引けばいいけど、文法が変わると結構つらい。

＠IT　あまりに自由に変えられるのはかえってよくない、と。

まつもと　Common Lispにはマクロがあります。それはつまり、括弧を使うという基本表現は同じでも、制御構造も含めてどんどん新しく増やせるってことですよね。Common Lispは、リーダーマクロもあるので、もうまったく新しい言語を作るとか、何でもありです。

＠IT　そういうのが気持ちいい人々には自由度が高くて心地よい。

まつもと　そうそう。何を作りたいかによるんですよ。Common Lispの人たちは、自分のアプリケーションに最適な「言語」を作りたいんですよね。

＠IT　言語デザイナと同レベル。

まつもと　そうそう。Common Lispでは、Common Lispが提供している言語をそのまま使うこともできるし、自分のアプリケーションや好みに合わせた、より上の言語を作るための素材としても使える。それはそれで、いいやり方だと思うんです。ただし、“自分言語”を作った後のコミュニケーションのギャップが大きくなっちゃうんですよね。だから、Rubyはそっちのほうは提供しないで、文法的なところは変わらないほうがいいという判断をしています。

RubyはDSLも支援

＠IT　DSL（ドメイン固有言語：特定の領域の問題を処理するために設計されたプログラミング言語）が注目されつつあるのかなと思ってるのですが、DSLも語彙セットの定義に収めたほうがいい？

まつもと　DSLって2つの考え方がありますよね。1つは、既存言語が十分に柔軟であれば語彙を追加するだけで、知識表現や構造表現が書けますよ、というものですね。もう1つはフリーハンドで文法から作る方法です。Lispの人たちは、基本構文は使うけど後はフリーハンドというやり方を好むんですね。2つのアプローチがあって、どっちがいいとは言えないんですけど、Rubyが支援するのは文法が変化しないで語彙が変化するDSLです。この有効範囲って意外と広いんじゃないかなと個人的に思っています。

yugui　DSLといえば、Rakeは初めて見たときにも確かに読めました。

まつもと　Rakeってmakeファイルの代わりにルールを書く、Ruby版のmakeなんですけど、これはRubyで書いたDSLで、ビルドのルールを柔軟に表現できます。

＠IT　例えばGNU makeに比べると楽なんですか？

まつもと　makeファイルで条件分岐なんかが入ってくると死にそうになるんですよ。シェルを呼び出したりして。一方、Rakeは特殊には見えてもRubyそのものなので、if文を書いていいわけですね。あるいは、処理の共通部分があれば、ここはメソッド定義しておこう、というのがあってもいいわけです。

予想より広かったブロックの応用範囲

＠IT　語彙も文法も自由だと、かえってコミュニケーションのコストが大きくなる。一方、文法を制限しても、語彙セットの切り替えや追加で、その応用範囲は十分に広いということでしょうか。この話は、高階関数とブロックの議論に似ている気がします。Rubyのブロックも、入れてみたら意外と有効な活用範囲が広かった、とおっしゃってますよね。

まつもと　そうそう、もともとブロックはループの抽象化のためだけにあったんです。だから最初の頃はイテレータと呼んでいました。でも、コンテキストの切り替えにも使えるんですね。さっきのRakeの例だと「ビルドとは、次のdoからendまでのブロックに含まれてる処理をすることである」と表現できるんですね。ファイルの入出力処理やスレッド処理でもブロックは有効でした。こうした処理の塊をうまく表現できたのは、ブロックの意外な応用範囲でした。もともとそんなことは全然考えていなかったですけど。

＠IT　Schemeが好きな人だと、そもそも関数オブジェクトとしてRubyがブロックを1つしか取れないのはなぜなんだ、そこに不自由さを感じるという話も聞きます。

まつもと　柔軟性や適応性でRubyがLisp（やScheme）に負けるっていうのは否定する気もないし、競争するつもりもないんです。ただ、50年間のプログラミングの経験の中で、よくやることって分かってるわけで、普段われわれプログラマはそれをやるわけです。そこの効率を追求するのは結構大事かなと。よくやる仕事のために最適化するのは重要なんじゃないかと思いますね。もちろん、だからといってそれほどプログラマの自由を制約しているつもりはありません。

ささだ　最初はまつもとさんの仕事が速くなったり、最適化されることを目指したと思うんですけど、今はどうなんですか？

まつもと　最初に作ったときには、ぼくと周りの人たちだけが使うかなと思っていたんですよ。でも意外と広く使われた。それってプログラマが日々直面している仕事のバリエーションが意外と少ないということを意味しているんじゃないかな、と。例えば、Rubyを作り始めたときは、Webってあったかなかったか分からないころで、RubyはWebを想定してデザインされていませんでした。でもWebの時代になって、「Rubyはいい、Rubyは使いやすい」って言ってもらえるのはプログラミングの本質はあんまり変わってないということかなって。状況が変わったり、適応分野が違っても、プログラマがこなす仕事のバリエーションは、それほど多くないんじゃないかと思うんです。

＠IT　デザインパターンみたいな話ですね。

まつもと　そそ、Rubyで8割か9割のパターンを支援する。実は98％かもしれない。ブロックを1つしか取らないのも、そうです。OCamlの統計に、こんなのがあるんです。OCamlのライブラリの2239関数のうち高階関数を使ったものがそもそも12.8％だけ。関数引数を1つだけ取るものが12.1％で、2つ以上の関数を取るものは0.7％しかないというんです。

＠IT　高階関数が多用されると思われる関数型プログラミング言語ですら、ほとんどの場合、1つで十分？

yugui　Rubyを書いていてブロックを複数渡したいと思ったことって、これまで数回しかなくて、そういうときは舌打ちしながらProcオブジェクトを複数渡すわけです。そういう逃げ道があります。Rubyは、よくあるケースを簡単にできるようにしつつ、逃げ道も用意してあって、汚いことをすればできるようになっていますね。

まつもと　Rubyにブロックしかなかったらまずいけど、lambdaがあるのでね（苦笑）

＠IT　複数ブロックを取る文法を考えて整合性を取ってやると、どうなるんでしょうか。

まつもと　うーんと文法考えてみたことがあるんですけど、改行をどこに入れるか分からないとかね（笑）

Rubyでは、まずメソッドは入力してみる

＠IT　ところでRubyを書いている人の間でIDE利用は増えているんでしょうか。Aptanaや3rdRailなど、いろいろ出てきていますが、EmacsやVimを使っている人も多そうです。

yugui　私はViです。起動がVimぐらい速いものがあれば、それでもいいんですけど、IDEでうれしいのって、せいぜいインテリセンスぐらいですよね。Rubyでインテリセンスが必要かというと、そうでもないですもんね。

＠IT　インテリセンスは初心者はうれしいんじゃないですか。

yugui　Ruby的に考えればこう書けるだろうと書けばそれでたいてい動くので、それでいいんです。それで動かなければライブラリ作者にパッチを送ったり、Rubyにパッチをコミットしたりする話なので。

＠IT　Arrayのオブジェクトを入力したらメソッドがずらっと出てくるとか、うれしいじゃないですか。

yugui　それはリファレンスマニュアルを頭から読めばいいんですよ。標準添付ライブラリ全部じゃなくても、組み込みライブラリは読みましょうよ。やっぱり言語をやるにあたって、コアライブラリを読まないと、知らないがために無駄な苦労することってありますから。

まつもと　読み物として、リファレンスマニュアルは電車の中で通読したほうがいいんじゃないかと（笑）

yugui　Javaを覚えるとき「プログラミング言語Java」を読んで、それからリファレンスマニュアルを頭から全部読みました。

まつもと　うわ、Javaは大変そう。java.langとか（笑）

yugui　私が読んだときはまだ今ほど多くなかったですしね。それに、意味は分からなくてもとにかく流し読みしてインデックスを作るのが重要じゃないですか。Javaを使うなら、最低限java.langとか、java.utilとかは全部読まなきゃ。

＠IT　専門の職業プログラマならそうでしょうね。私はRuby 1.9に入ったArray#shuffleって知らなかったんですね。それを知らずに自分でメソッドを書いてたら、shuffleがあるよと指摘されたんですね。それって、IDEが、こんなのあるよと提示してくれていたら、「あ、なんだshuffleってあるのか」と分かっていいかなと思ったんです。

yugui　それは、コレクションがあってシャッフルしたいと思ったら、shuffleと書いて、それで動かなきゃいけないんですよ。

＠IT　なるほど！

まつもと　あっはっは。シャッフルできるはずだと。できなければRubyのバグだと。

yugui　実際、shuffleが入ったのは割と最近ですよね。それはRubyが間違っていたから直したんですよ。

まつもと　まあ、yuguiさんは、そういう脳内モデルを持ってらっしゃいます（笑）ぼくはもうちょっとルーズなんですよね。Arrayのメソッドとしてshuffleがなかったのは間違っていたっていうか、気がつかなかったね、ごめんって感じなんですけど。

メソッドもたくさん増えたRuby 1.9

＠IT　Arrayにはいろいろ入りましたよね。productとか。何で今までなかったんだ、という、うれしいのもあります。

まつもと　Arrayにはproductもcombinationもpermitationも入りました。なんでもありです（笑）

＠IT　中は大変にならないんですか？

まつもと　まあメソッド単位で増えるのは線形な増加なのでそうでもありません。機能を組み合わせるほうはシンドイですね。C++のテンプレートのようなものは複雑になりますね。

＠IT　これまでメソッドをリジェクト（提案を拒否）した例ってどういうのがあるんですか？確かにこれはあると便利だけど、不要だろうという理由で。

まつもと　いっぱいありますけど、例えば昨日やったのはEnumerable#to_hashですね。2要素の並びのEnumerableがあったら、それから要素を1個ずつ取ってきて、2要素でhashを作るっていう。だけど、2要素のEnumerableってあんまり一般的じゃないよなーって。

yugui　名前が良くないからという理由でリジェクトするってありますよね。

まつもと　ああ、良くあるよね。こういう機能が欲しいんですけどって言われたときに、まあそういう機能があったら便利なのは認めよう、ユースケースも分かる、でもその名前はダメっていうこと（笑）いい名前が決まったら採用しますよと言ってリジェクトしたことは数え切れないほどありますね。

理想のVMはRubinius

＠IT　先日、Smalltalkコミュニティの方と話していたら、SmalltalkではVMレベルで継続をサポートしているのがいいという話でした。JVMは継続をサポートしていないので、JVM上では言語レベルで継続を自然な形で実現できない、と。そういうのものなのですか？ YARVだとどうなんでしょう？

ささだ　Rubyレベルで継続はサポートできませんから、Cでという話になるんですよね。ただ、継続を諦めることのメリットもあるので、どこをどう重視するかなじゃないかなと思います。VMよりも、処理系全体を見て考えたほうが正しいと思うんです。CRubyだと、すぐにCに落とせるというところに重きを置いているので、今のVMの形式や、処理系全体がある。そもそもCRubyだとJavaのJVMに比べて、すごくVMが薄いんですよ。

まつもと　JVMは、すべてのライブラリがバイトコードになってプログラムはその上で実行されるんですけど、YARVの場合は、すぐにCになるんだよね。

ささだ　それは設計上の方針です。Smalltalkのように処理系の設計者がすべてコントロールするというのと、すぐにCに落としていろんなことができるというCRubyのポリシーは相反するので、その違いですよね。Cでちょこちょこと書ける人はCで書けたほうがいい。でも、そうするとCで書いても大丈夫なように保守的に作らないといけない。メリット、デメリット、いろいろありますよね。

yugui　Rubiniusってどうなんですか？

ささだ　うらやましいですね、あれは。計算機屋としての理想はRubiniusのようなアプローチです。

＠IT　基本的なところですが、VMとしてYARVに比べてRubiniusのアプローチがいいというのは、どういう意味ですか？

ささだ　Rubiniusは全部Rubyで書いてあるんですよ。Ruby自体が速くなれば当然速くなるんです。Rubyの処理系が遅かったら、Rubiniusも遅いですけど、Rubyに最適化技術を適用していけばRubiniusはガツーンと速くなる。Rubiniusに人的、時間的、経済的リソースをつぎ込めば最高のVMができると思います。でも、Rubiniusについては方針が素晴らしいと言ってるだけで、Rubiniusそのものがいいかどうかは分かりません。

＠IT　現状ではまだダメ？

ささだ　少なくとも5年とか10年といった単位で時間がかかると思います。Javaが1995年に出てきて、まともに使えるようになったのはいつ頃ですか、というのと同じです。サン（サン・マイクロシステムズ）がJavaにかけてきたリソースをRubyにもかけられますかと考えると厳しい。もちろん、VMに関しての知見は論文にもありますから、それを再実装するだけなので多少はマシですが、どのぐらいかかるのだろうかと考えると、私はRubiniusは結構難しいんじゃないかと思いますねぇ。

＠IT　パフォーマンスでYARVに追いつけない？

ささだ　Rubyカンファレンスで「理想はRubinius」だよね、という話をしたことがあるんですけど、その話には続きがあります。Rubyが高速化すればRubiniusは高速化するので、性能向上のグラフでは、勾配はRubiniusのほうが急です。だから将来どこかの時点でYARVとRubiniusのパフォーマンスは入れ替わるはずです。ただ、私のプラグマチックな観点からは、そのクロスポイントは永遠にやって来ない。ただし、Rubiniusを作っているエバン・フェニックスが、私が思っているよりもすごいハッカーだったとか、Railsみたいにプロジェクト自体が燃え上がっちゃうとか、そういうのがあると分かりませんけどね。

＠IT　Rubiniusのようなアプローチを取っているのは？

ささだ　JavaもSmalltalkもそうです。正しいアプローチです。成功例はいくつもあるので、Rubyで同じことができないということはないと思いますけど、今の体制だと無理かなという感想ですね。CRubyは、その中間ぐらいを目指すのかなと思ってます。Rubyの中にCを書く仕組みがあるんですが、Rubiniusのように全面Rubyじゃなくて静的なところはCで書いてコンパイルする、と。そのへんが落としどころじゃないかなと。

静的言語と動的言語のせめぎ合い

＠IT　Ruby、Python、JavaScriptなど動的言語の人気が高まる一方で、近いうちに静的言語への揺り戻しがあるんじゃないかということを言う人が多いように感じています。例えば今後、型推論のような仕組みが流行することはありそうですか？ Rubyは？

ささだ　Rubyに型推論を入れるというのは、みんな考えていて、個人でいろいろ作っている段階でしょうか。yuguiさんは「yarv2llvm」の動向を追っていますか？名古屋の三浦さんという方が取り組んでいるんですけど、あれは本当にすごい。全部型推論でやろうとしていて、あのアプローチでどこまで行けるのか楽しみです。どこまで現実的か分かりませんけど、ぜひ突き進んでいただきたいですね。

yugui　それだけちゃんと型推論で動いているのはすごいですよね。

＠IT　型推論ってパフォーマンスが上がるんですか？

ささだ　ええ、型付きプログラミングの目的にはパフォーマンス向上とバグを少なくするというのがあると思うんですが、型付きプログラミングを支援するのが型推論ですからね。ソフトタイピングという技術で、変数の型を伝搬させていくというものです。それができるまでやる。できないところは分からないものとして扱う。言語処理系というのは、決まっている情報が多ければ多いほど最適化して速くできるので、コンパイルするときに型が分かってるといいんですよ。コンパイラの技術って「どこまで読み切るか」なんです。例えば昔のベクトルマシンなんかだと、どこからどこまでデータにアクセスするかをプログラム全体から読み切るんです。読み切ると、ここの領域のデータはベクトルレジスタに入るという風に最適な形にできる。動的言語の何がまずいかっていうと、分かる情報が少ないことなんです。

＠IT　今さらのようですが、静的型のデメリットは？

ささだ　アルゴリズムだけ書いておいて、どんなデータでも適当なデータを渡せば処理してくれるっていう“ダックタイピング”のような処理は、静的型付けでは書きづらいんです。

yugui　C++がテンプレートで、それを経験して結局コンセプトを入れました。これからC++0x（C++の次期標準規格）がそれにまつわる地雷をひと通り踏んでくれると思うので、C++が成熟した段階で、果実だけでもRubyに持って来られればいいなーと私は勝手に思ってるんですけど。

＠IT　中長期的な話なんですね。

ささだ　プロセッサだと集積度が1年半で倍々という話もありますけど、言語だと10年で1.5倍とかですよね。何が1.5倍か分かりませんけど（笑）

＠IT　プログラマの変化は、それに輪をかけて遅いという話もありますよね。

ささだ　どんなにいい言語を作っても、使われないとダメだし、使われるには知られている言語じゃないとダメですからね。HPCの人たちはFORTRANを使っていますし、今後もCは絶対なくなりませんよね。向こう50年はなくならない……、のじゃないかなと思ってるんですけど、どうでしょうね？

yugui　今のプロセッサアーキテクチャが大きく変わるまではCは使われるんでしょうね。

ささだ　並列がそれを変えるまでに、Cに代わる言語やプログラミングモデルが一般化するかというと、よく分からない。OpenCLなんかCを念頭に書いてますよね。やっぱりCの拡張になるのかな、とかね。

＠IT　NVIDIAがGPGPU用SDKの「CUDA」をCベースにしたのは、その辺が理由という話でした。最近何かのホワイトペーパーで見たんですが、HaskellでGPGPUをやるとCより2、3割速いっていうんですよね。でも、Haskellなんか使ってたら誰もCUDAを使ってくれなかっただろうと、NVIDIAの担当者が言っていました。Cを使ったからこそみんな使ってくれたし、成功したと。

ささだ　Haskellのほうが読み切れる情報が多いからパフォーマンス上は有利でしょうね。Cだと、どこからどこまでデータにアクセスするかという解析は、一般的に難しいとされています。でも、並列プログラミングに限らず、いま難しいと言われてる言語やプログラミングのパラダイムが、一般にまで広まるかというと、それはないように思うんですよね。

＠IT　漸進的な対応になっていくんでしょうか。

ささだ　例えばRubyでも、この作法に従って書いてくれれば最適化が効きますよというのはできますよね。これこれの書き方は諦めてください、とか。プログラマがちょっと工夫することで処理系が「読み切りやすい」ようにはできます。結局その辺はトレードオフですからね。処理系にヒントを与えて最適化をやりやすくするか、人間には役に立たない情報を省いて記述のシンプルさを取るかっていう。この対立軸でいえば、ユーザーが楽になる方向にグーッと押し進めたのがRubyで、逆に処理系側に押し進めたのがC++、というのが私の理解です。

＠IT　処理系が最適化しやすいように補助的な情報をRubyにも埋め込むとか？

yugui　Rubyはメタ情報をコードに与える記法として標準のものがないから、そういう試みはたいてい発散しちゃうんですよね。何か1つ標準的なものを提供して、はやりのアトリビュート記法を入れれば、その中で試行錯誤してる間に何かいいものが出てくるんじゃないか思うんですけどね。

クラウド時代のRubyとは

＠IT　まつもとさんに「クラウドをどう思いますか」と聞いてみたかったんですけど（笑）

まつもと　クラウドってなんですか？（笑）私にクラウドの定義を示してみなさい、そうすれば……という聖書みたいな返答をしてみましょうか（笑）

一同　ははは（笑）

まつもと　クラウドが何かはともかくとして、1人のプログラマ、いや、1つのプログラムが使うことのできるリソースの数や量が増えているのが現実だと思うんですよ。最近はデュアル・コアがふつうになってきて、メニーコアも出てきています。クアッド・コアぐらいまでは、ふつうに電気屋さんで売ってたりしますよね。そういうときに、それを活かす技術がRubyの中で必要だなとは思っています。でも、正直、いまRubyはメニーコアに向いたデザインになっていない。

＠IT　Rubyの並列プログラミング対応はどういうアプローチになるのでしょう？

まつもと　複数プロセスに処理をばらまくとか、簡単にスポーン（spawn）しちゃって、それぞれで仕事をして、通信して結果をまとめるとか、やり方はいろいろですね。プロセスを複数に拡張するのもあるだろうし、1つのプロセスの中で複数のVMを走らせるのもある。あるいは、いまRubyでグローバル・ロックを使っているのを、細粒度ロックにしていくっていうのもある。いろいろアプローチがあって、どれが唯一の正解ってのはたぶんなくて、それぞれにやっていかないといけないな、と。そういう技術を蓄めておくと、クラウドという話になったときにも対応していけるんじゃないかなと思います。

ささだ　プロセスレベル、マシンレベル、拠点レベルなりで並列分散実行をどうするか、それを簡単にする仕組みって必要ですよね。今みんなそれに取り組んでいますよね。

＠IT　クラウドといいえば、Google App EngineではJRails on Rubyも動いてます。もうJVMでいいじゃんっていうことになる危機感は？

まつもと　危機感どころか、JRubyがなかったら、今でもRubyがApp Engineで動いてなかったわけだし、JRubyがあって良かったなって（笑） JRubyもRubyだし。ぼくはCRubyが絶滅してもJRubyで“象徴”として生きる道があるから（笑）