NewsInsight

日本語と英語の言語の壁、RubyとRailsの壁

RubyKaigiが開催、テーマは「衝突と解決」

2010/09/13

　コミュニティ主導の年次Ruby関連イベント「RubyKaigi2010」が2010年8月27日から3日間、茨城県つくば市のつくば国際会議場で開かれた。RubyKaigiは今年で5回目。年々規模は大きくなっていて、今年の参加者数は747人と、言語コミュニティのイベントとしては最大規模となりつつある。

オレのパッチ入れて！ 中2がRubyコミッタに迫る

　初日金曜日（27日）の午前は「Ruby開発会議つくば」で幕を開けた。

　開発会議は文字通り、Rubyのコアコミッタや各プラットフォームのメンテナが現在進行中の問題を公開ディスカッションの形で話すというもの。普段メーリングリストで議論していることを、リアルに話し合う様子を見るため、あるいは提案をするために、小さな会議室に立ち見が出るほど参加者がかけつけた。

　話し合われた主なトピックは、「1.8系の開発の今後」「Ruby 2.0に向けた予定」「Rubyのライセンス変更の提案」「Windows向けCRuby処理系の1つ、mswin32版のメンテナ引き継ぎについて」「新デバッガの提案」など。実装や機能の詳細よりも、開発ロードマップについての認識を確認して、ラフな合意を形成するという議論だった。

　目を引いたのは、「オレのprependをRubyに入れてください！」とマイクを取った中学2年生のsora_hさん。RubyのStringクラスに、レシーバの文字列を破壊的にその文字列の手前に加えるprependというメソッドと、演算子風に見える「"add" >> str」という記法を追加してはどうかという提案で、今月頭にメーリングリスト上で議論していたもの。「対称性からprependだけでなく、appendも一緒に入れるべき」「そもそもprependは英語にない単語」「いや、コンピュータ用語としては定着している」「何に使うのかユースケースが思い付かない」など、さまざまな意見が出た。

　結局のところ、演算子のほうは影響が大きいため取り込むのは難しいが、prependは入れてもいいのではないかという話で落ち着いた。とはいえ、現在CRubyのゲートキーパー的役割を担っている1.9系のリリースマネージャー、yugui氏は、「まずはActiveSupportにパッチを投げてみては」と提案。Rubyにないメソッドを多く定義しているRuby on Railsのライブラリにまず入れてみて、もし多くの人に使われることが分かったら、それからRuby本体に取り入れても遅くないのではないか、と話をまとめた。

　ただ実際には、この話し合いの後の夕方には、Rubyの開発版であるTrunkに、sora_hさんのパッチは取り込まれた。

Rubyコミュニティが抱える衝突

　たとえ中学生からであろうと提案があれば公平に扱うし、よい提案なら受け入れるというオープンさがあるRubyの開発コミュニティだが、一方で「言語の壁」による分断は、Rubyの未来に大きな影を落とし始めているのかもしれない。

　RubyKaigiでは、毎年イベント全体を貫くテーマを設定している。テーマは、その時々のコミュニティ全体の問題意識や期待感、あるいは自分たちの手で未来を開いていこうという意志や呼びかけを端的に示すメッセージだ。

　今年のRubyKaigiのテーマは、「Conflicts and Resolutions（衝突と解決）」。Ruby on Railsの成功で広がったRubyの世界は、JRubyやMacRubyなど処理系の数も増え、使われ方は多様になった。その結果、異なる種類の利用者の間で衝突、もしくは軋轢（あつれき）も生まれている。

　Ruby開発の中心となるメーリングリストには、英語と日本語の両方があるが、例えばJRuby開発者の1人、チャールズ・ナッター氏は、英語を読んでいるだけでは大事な議論が見えてこないことにもどかしさを感じる、という。「JRubyやRailsは、英語の世界。でもRubyは違う」（ナッター氏）。初日午前の開発者会議の会議室でも、いちばん後ろの席にひっそり座り、日本語の議論を追えるでもなく、たまにプロジェクタに映し出されていたIRCの議事録を見るために顔を上げるという感じだった。日本人のRubyコミッタが英語でやり取りする場面もあったが、もし言語の壁がなければ、もっと海外の参加者は活発に議論に参加できたことだろう。

　Ruby on Railsのコア開発者で、現在もっとも精力的にRailsに貢献している1人でもあるヤフーダ・カッツ（Yehuda Katz）氏も、初日に行われたパネルディスカッションの中で、その違和感をこう述べる。「（Rubyの開発メーリングリストで）何かを提案をすると、私の名前が何度も引用されて議論されていることは分かるけど、日本語なので内容は全然分からない」（カッツ氏）。長い議論の末に、最後に英語でヒトコトだけ、“no”とあって提案が却下されたことだけを知る。議論が読めれば、何か自分の視点から議論に貢献できるかもしれないのにと、もらす。

　言語仕様の変更についても摩擦がある。最近非常に大きかったのは、Ruby 1.8から1.9へのバージョンアップで、文字列のエンコーディングの扱いがガラリと変わったことに対する欧米のRails開発者、利用者たちの違和感だ。日本語のようにマルチバイトの文字コードや、多数のエンコーディングを扱う必要がある開発者からすれば、Ruby 1.9の文字列の扱いは1つの理想を実現しているが、アスキー文字列以外の扱いに慣れない開発者には、不意に面倒が増えただけに見える。

RubyとRailsの間の距離

　RubyとRailsにも距離がある。

　オーストラリアや北米など海外からRubyKaigi2010に参加していた人々に話を聞いてみても、Rubyコミッタとして名前が知られているのは、まつもと氏だけ。これは日英の言語の壁というよりも、Rails利用者の感覚を示しているように記者には思われる。Rails利用者がローレベルの実装に目を向ける必然性は必ずしもない。

　「RubyKaigiはRubyをテーマにしたC会議だ」という指摘がある。実際、気付けば実装の話、Cのコードの話をしているというセッションが多かった。

　2日目の基調講演でまつもと氏は、Ruby 2.0へ向けた機能の1つとして、「mix」の構想を説明した。将来的にincludeに代わり得る、名前衝突による予期せぬ動作が避けられるmixinの新しい仕組みだ。サンプルコードはもちろんRubyで示したが、映し出されるスライドの多くは、Cで書かれたRubyのソースコードだった。

　また、Rubyのガベージコレクタ（GC）に「lazy sweep」というアルゴリズムを採用することで、停止時間を短くする新実装（先日リリースされたRuby 1.9.2に間に合わず、1.9.3に入る予定のもの）を解説した中村成洋氏のセッションも、Rubyというよりも、言語処理系一般のガベージコレクタの戦略についての話だった。

　東京大学の芝哲史氏は、3日目に「Ruby AOTコンパイラ」（Ahead-Of-Time）の研究成果を発表した。これはRubyで書かれたコードをCに変換してgccで機械語に落とすことで高速化するという試みだ。マイクロベンチマークで1〜3倍程度に高速化するものの、Railsやテキスト処理といったマクロベンチマークでは、逆に1割から2割ほど遅くなる。CPUの命令キャッシュに乗り切らなくなるからだろう、という。中間に生成されるCのソースコードは、大きいもので25万行にもなり、gccがメモリ不足で落ちる、というようなことがあるという。

　RubyKaigiはRubyをテーマとしたC会議、というのは半分は冗談だが、そこには言語処理系に手を入れるCハッカーへの憧憬も混じっていそうだ。言語処理系は、OSやデータベースなどと並んで、優れたプログラマが最終的に行き着く総合芸術というような面がある。そして、日本のRubyコミュニティは、こうした人々が集まる梁山泊となりつつあるようにも見える。

　少なくとも、GCやコンパイラの話に目を輝かせる層と、米国で規模が拡大しているRailsConfに来る「Rails開発者」の間には大きな隔たりがあるだろう。こうした点でもRubyとRailsの溝は小さくない。

　もう1つ、溝があるのはRubyとJRubyの間だ。

　RubyKaigiと併催されたサブ・イベント「JRubyKaigi2010」にはJavaコミュニティから来た人々が多く、逆に、もともとRubyやRailsを使っている人たちは、あまり関心を示さないという現実がある。JRubyはすでに十分速く、堅牢だ。多くのRubyistがそうしたウワサを聞いて、試してみてもいる。しかし同時に、classpathの設定が面倒だとか、何か問題が起こったときに、Unixの1プロセスでしかないシンプルなCRubyと違ってスタックトレースを見て解決というわけにいかず、JRubyだとどうしてよいか分からない、あるいは、そもそも起動が遅いといった声も聞こえてくる。Ruby/RailsとJRubyの間にも分断面が存在している。

衝突から解決へ

　多様性の結果として、衝突やギャップが生まれる。そうしたギャップを積極的な交流で埋めていこうというのが、RubyKaigi2010のテーマ「衝突と解決」に込められた思いだったのだろう。

　言語の壁について言えば、3日間のイベント期間を通して、日本語のセッションに参加する外国人、あるいは英語のセッションに参加して質問をする日本人など、言語の壁を超える努力は双方ともしているのは印象的だった。ほぼすべてのセッションで、ボランティアがIRC上で講演を翻訳して、それをプロジェクタで映し出していた。RubyとRailsの両方のコミッタという稀有な存在で、流暢に独創的な日本語（例えば、こことか、ここ）を操るRubyist、アーロン・パターソン氏は、初日のパネルディスカッションで、言語によるRubyコミュニティの分断は「将来大きな問題になるかもしれない」と指摘すると同時に、日本語と英語について「互いに互いの言語を学ぶことが大事。そうすることで双方とも得るところが大きい」と語った。

　Ruby/Rails、あるいは日英のギャップというのはあるが、見方によれば、その距離は縮まっている。もともとRailsは、日本のRubyコミュニティと離れた場所で生まれて大きくなった。そして現在、互いに互いの存在を発見するような形で近づいていると見ることができるのではないだろうか。日本で有数のRails利用企業として知られるCOOKPADの英国人エンジニアは、3日目に開いたセッションの中で、シリコンバレーから日本へ転職して来るときに想像していたほど、COOKPADでの仕事の進め方には大きな違いはなかったと自らの体験を振り返っていた。どちらでもMacBook Proを使い、Railsを使い、TextMateやvimを使っている。使っているプラグインやミドルウェアも同じだ、という。

　東京には活発な地域Rubyコミュニティがいくつか存在しているが、それとは別に、東京在住の外国人Rubyistなどの呼びかけで「Tokyo Rubyist Meetup」と名付けられたコミュニティが立ち上がろうとしてる。開発者だけでなく、利用者コミュニティにも言語間での分断があったのだとしたら、これは注目すべき動きだ。Tokyo Rubist Meetupは、「日本のRubyistと世界のRubyistとをつなげるための場になることを目指して設立」したといい、9月22日に第1回のミーティングを行う予定という。

　Railsは英語圏から日本に流れこんできた“逆輸入”プロダクトという側面がある。そして、Railsという現象は単なるWebフレームワーク以上のもので、プログラミングのスタイルや開発プロセスにも大きな影響を与えようとしているように記者には思われる。“ポストRails”とも呼ぶべきそうした現象については、別稿でレポートしたい。

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