_ まつもとゆきひろ×結城浩，Rubyを語る

たまには、ざっくばらんに書かせてもらいます。

結　変えようとするところが，スゴイと思います。変えないほうが楽ですよね。

私には全く信じがたい言葉です。 まともなソフトウェア開発をやっている人間なら、決してこんな言葉は吐かないはず。 普通、ソフトウェア開発をやっている人間には次のパターンが存在するように思います。

1. もう関心がないので、実は放置したいと思っているか、実際にそうしている。
2. やる気あり。どんどん改善できるところはやりたい。でも既存のユーザを無視できないので、そう簡単には変更できない。
3. やる気あり。もういっぱい変えたくてたまらないし、実際にそうしている。ユーザなんて知ったことではない。

私が思うに、結城さんが言っているのは最初のパターンで、 こんなのはまともな状態とは言えないのだから、 変えない方が楽とかじゃなくって、何もしないのが楽って言っているだけです。 放置プレイ。 そんなのは開発とは言えません。

大体において、開発というものは最初の頃が一番楽しいものですが、 それは三番目のパターンが簡単に適用できるからです。 そもそも利用しているユーザがいない状態なのだから、 変えようが変えまいが、気にする必要もないわけです。

しかしこれを本当に使われている状況でやられては、たまったもんじゃありません。 それと同時に、開発を多少なりとも経験している人なら分かるように、 互換性に注意して改善するのは、相当気を配る必要があり、 制約も厳しくて、大変な作業です。 変える方が楽なんです。 それはもう、圧倒的に。

それでもやる価値あるのは、いわゆる最大多数の幸福の法則などが理由にあげられるのでしょう。 大変だとは言っても、所詮1〜数人のコア開発者が苦労すれば、何万というユーザが助けられる勘定になるから。 作っている人のハッピーよりも、使っている人のハッピーの方が、総量として大きいという考え方。

だから、まともな開発者なら、いかに「変えながら変えないか」を考えます。 具体的な方法論はさまざまあるでしょうが、 例えば、互換性を保ちながら拡張するとか、 新しい記法を導入するけど古いのもサポートするとか、 バージョンできれいに分けてしまってユーザにも少し苦労を肩代わりしてもらうとか、 そんなところでしょう。

とにかく、作っている人が変えたくなるのは当たり前の話。 一番欠陥の見える位置にいるんだから。 そこを変えないように改善できて、なんぼのもんです。

さて、並列化のお話。

ま　個人的にはもっと自動的にやって欲しいんですけど。人間が考えることはできるだけ最小限にとどめて，あとはコンピュータがよしなに計らってくれる，というのが好みなんです。

私は根本的に脳味噌が古いのか、あるいは、近視眼的になっていて、将来の変化が見通せていないのか、思い切り外しているという可能性は大いにありますが、 どうもこの話題には悲観的な見解しか持ち合わせてません。

ちゃんとした話を書こうとすると、少々大変なので、かなりはしょって書いてしまいますが、 少なくとも現在のコンピュータでは、何が内部で行われているのかを理解せずに済ませられるほど、性能がよろしくありません。 ディスクI/Oは恐ろしく遅いし、ネットワークI/Oも相当遅いし、 ネックがCPUにはほとんどならない。 そりゃ一部の科学計算（という用語も何だかあれだけど）ではそういうこともあるけれど、 私のよく知る範囲では、そういう例は極めて稀です。 コアが増えたからと言って、単一ノードで収まったりはしなくて、 分散化が必須という状況では、 言語なり処理系なりが透過的な機能を提供して、それで本当に嬉しいの？と思うのです。

そりゃあ、中にはいわゆるバカチョンパラレルで十分なケースもあるわけで、 そういう時には嬉しいのかもしれません。 でもそれだけでは困る場面というのは、無視できない程度には多々発生します。 そういうときに、うーん、一体何がどうなっているんだろうと悩み、 そこに人間が介入できるかどうかを悩み、 事態がややこしいことになるぐらいなら、 私はもろなインターフェースが見えている方が嬉しいと感じます。

それはそれとして、また別の考え。 仮に、いっぱいコアなマシンが普及したとします。 例えば、8コアになったとしましょう。 全部のコアが単一のプログラムのために費されるのもどうかとは思いますが、 とりあえず全リソースを投入したとして、 それでも最大8倍にしかならんのですよね？ そこまで線形に増大するとも思えないけれど、 ここは楽観的になるとしましょう。

で、この8倍とはいうのは、CPUに関する部分だけなわけですよね？ つまり、この恩恵を受けられるのは、CPUがボトルネックになるようなプログラムだけなんですよね？ でもね、CPUがネックになるようなタイプのプログラムなら、 そこをCで書き直した方がたったの1コアでも、もっと速くなるんじゃないですか？ Rubyでそういうプログラムを書く意味って、どれぐらいあるんですか？

より開発効率の良い言語で、速度の向上が見込めるところに意味がある、 のかもしれません。 でも、その結果が、たくさん電力を消耗して発熱量を増大させて、その挙句、結局Cより遅いです、では、ちょっとね。

あるいは、信じがたい数のコア数になれば、とんでもないことになるぞ、という話なのかもしれません。 例えば、4096コアとかになれば、確かにすごいことになるのかもしれません。 でもねえ、Rubyのような動的言語のメモリ効率がよろしくないという状況が今後改善されるようには思えないから、 キャッシュ効率も悪くって、急激にスケーラビリティが落ちていくようにしか思えないんですよね。 こっちは何一つデータを持ち合わせてないので、因縁をつけているような気もするのが申し訳ないですが、 誰かシミュレータとかで計測したりしているんでしょうか。

個人的には、コンピュータが何でもよしなにはからってくれる、という構図は全然信じてなくって、結局人間が面倒を見ないといけないことは随分多いと感じています。 O/Rマッパーが嫌いなのと同じ感じ。 それでも済む程度のしょぼいレベルならともかく、 そうじゃなくなったときに、より一層苦労させられるような隠蔽化は邪魔ものでしかなくって、 それなら初めからない方がマシっていう。

とは言いつつ、dRubyに毛が生えたような程度のものがあったら、案外便利な場面もあるかもなあと思ったり。 何が起きているかはっきり分かるようなものがいいな。

_ 逃避

とか余計なことをやってないで、発表の資料作りをしなきゃ！