0016 号 巻頭言
まだ死ねずにいる 1.8 系のために
Rubyist Magazine 第 16 号をお届けする。
今号は 2 周年ということもあり、 二周年記念企画として多数の方からありがたいメッセージを頂戴した「Rubyist Magazine へのたより」、 Amrita 作者でもあり「google 八分」という言葉の命名者でもある多芸多才な essa さんをお招きした「Rubyist Hotlinks」、 PStore とそれを利用した永続化クラスを紹介する「標準添付ライブラリ紹介」、 日本語プログラミング言語「なでしこ」を、作者自らが紹介する「Rubyist のための他言語探訪」、 先日行われた LL Ring の詳細を伝える「Lightweight Language Ring 観戦レポート」、『初めてのプログラミング』『プログラミングRuby 第2版』『たのしいRuby 第2版』『みんなの Python』といった、最近発売された Ruby や Python の書籍を紹介する「書籍紹介」、 出版社各社さまのご協力による「読者プレゼント」、 さらに「0016-RubyNews」に「0016-RubyEventCheck」と、 いつものように盛りだくさんの内容になっている。
先日、東京は新木場で Lightweight Language のイベント「LL Ring」が開催された。 その名の通り、プロレスリングで行われたこのイベントでは、毎年恒例の各言語の最近の動きを紹介する「Language Update」があった。 そのうちの Ruby の Update を紹介したのはまつもとさんであったが、 その発表の中で衝撃的な「引退宣言 (？)」が飛び出した。 もっとも、これは「Ruby 1.8 系から」、という限定はつくのだが。
ところで、なぜ今「引退」なのだろうか。
同じく LL Ring の発表でも触れられていたが、 1.9 系は、2007 年の 12 月にリリースされることがアナウンスされている。 まだ 1 年以上先ではあるが、1.9 に盛り込まれる内容を考慮すると、 そのα版を 1 年前にリリースしておいても早すぎることはないだろう。 あるいはα版リリースまでにもっと時間をかけるという選択肢もあるが、 その場合、最初にリリースされる 1.9 は新機能・新仕様の発表が目的となり、 安定性や使いやすさはあまり高められないかもしれない。
一方で、Ruby 1.8 系については、最初にリリースされたのが 2003 年 8 月 4 日。 それからすでに 3 年が経過している。 そのため、1.8 系で動くことを前提として作られたライブラリやアプリケーションは、 1.8系の普及を大きく牽引した Ruby on Rails を筆頭に多数ある。 それら Ruby 製ソフトウェアの利用者としては、 そのソフトが自分たちで運用しなければいけない間、 安心して動かすことのできるプラットフォームを期待している。 しかしながら、1.9 の開発を進めながら 1.8 についても手厚いサポートとメンテナンスを行い続けることは難しいように見える。
そのために、Ruby を利用している企業がメンテナとなる、 あるいはメンテナを雇用する、という解決案がある。 これは実現できたとすれば理想的な形ではある。 現実問題として、 今後 Ruby が企業のソリューションとして利用されるのであれば、 否が応でも 1.8 系で動くアプリケーションのメンテナンスを、 今後数年以上のスパンで行わざるをえなくなるだろう。 1.9 がリリースされた後、しばらくの間は 1.8 系のメンテナンスも行われるだろうし、 メンテナンスが終了したからといってすぐにも一切の環境を廃棄せざるをえなくなることはないだろうが、 いずれにしろ実行されているアプリケーションを 1.9 へ移植しなければ、 現行のままでは安定利用が困難になる。 すでにあるアプリケーション、今後 1.8 系で開発されるアプリケーションについて、 そのくらいの時期には移行・廃棄するようなライフサイクルを想定できる場合は問題ないだろう。 しかし、それ以上のライフサイクルを期待しなければならない場合は、 導入した企業の責任で保守サポートを行わなければならないかもしれない。
とはいえ、実際にはシステムを維持するコストを払うよりは、 いっそシステムを移行してしまった方が適切な場合も少なくないだろう。 また、今のところ、1.8 系のメンテナを雇用するコストを払う企業も、 またそのことに興味を示す企業も、現れていないそうである。
それにしても、どうしてこのような解決策を考えなければならないのだろうか。 それはつまるところ、「1.8 系についてはあまり大きな変更を加えることができない」という方針に集約される。 しかし、その方針は、現在の Ruby の開発体制にとって、ある種致命的なものではないだろうか。
現行の Ruby は、まつもとさんという、言語設計者の手により実装されている。 私見では、まつもとさんの興味の比重は、言語の実装よりも言語の設計に偏っている。 つまり、現在の Ruby の開発のモチベーションは、言語の設計によるところが大きい。 言語の設計は、言語仕様の変更に大きく関わる。 もちろん現状の仕様を崩さず適切な仕様の拡張を施す、 ということも言語設計の醍醐味かもしれないが、 それでは自由度が小さい。 まつもとさんの好きな「nil.to_s の返す値は “” であるべきか “nil” であるべきか」といった楽しい議論は、 Ruby 1.8 系の元では永遠にできないだろう。 そのような状況で、ただでさえ負担の大きい異なるバージョンの保守のコスト負担を強いることは非常に困難である。
結局のところ、1.8 系は、「(言語設計者としての) まつもとさんのためのもの」ではなくなりつつある。 そして Ruby の仕様を握っているのがまつもとさんである以上、 Ruby 1.8 系は事実上すでに死んでしまっているのではないだろうか。
このことは、Ruby 1.8 系が Ruby のアプリケーションを開発する人々にとって、 まさに今、生き生きとした旬の言語であることとは、一切矛盾しない。 皮肉な言い方をすれば、「(ある種のユーザにとっての) 良い言語は (設計者にとって) 死んだ言語だけ」、と言ってもよい。
そうであれば、 いっそのこと今後の 1.8 系に関しては、明らかなバグフィックスを除き、 一切の機能拡張を終了する、と宣言してもよいのではないだろうか。 さらに、バグが見つかっても、あらかじめ定めたリリース日程内で修正することができなければ、「既知のバグ」として、 アナウンスのみ行って修正は行わないままリリースすることも想定してもよいかもしれない。 すなわち、ソフトウェアとしての 1.8 系の開発は事実上終了し、 あとは保守サポートのみにしてしまうことになる。
これはあからさまに後ろ向きの対応だが、 逆に 1.9 に対しては前向きな対応だと思ってもらえるかもしれない。 ここで 1.9 のリリースができなければ、 Ruby そのものが開発終了するように見えかねない。 退路を断つことによって 1.9 リリースへの本気度は否が応でも内外に示されるし、 また Ruby の開発のリソースを 1.9 に注力することは、 1.9 のリリースを迅速に行うことにつながりうる。 とはいえ、実際のところ、1.8 への機能追加や 1.9 からのバックポートについては、 それ自体が負担になっているかどうかはまた別の話であり、 これらを止めたからといってメンテナンスが楽になるとは限らない (たいして楽にならないような気もする)。むしろ象徴的な意味合いの方が強い。
……などということを、コミッタですらない私が書くのは僭越でしかないし、 的外れかもしれない。 少なくとも開発者の方々の意識を余すところなく代弁していることはありえないだろう。 それでも、1.8 系に対する需要と期待の急増が保守に割かれるリソースに結びつかない現状に対する問題意識は広く共有したいと考え、 思うところを書き記してみた。
(るびま編集長 高橋征義)