退屈は最大の敵
まつもとゆきひろ氏：次はPerlですね。ここまでですでに4回ぐらいPerlの話題が出てきています。なぜかというと、私はPerlが大好きなんですね。実は、Perlが大好きなんですが、Perlのプログラミングは大好きじゃないんですね。あと、Perlのソースコードも大好きじゃないんですね。
ですが、Perlには非常に精神的に、あるいは哲学的に影響を強く受けました。なのでこの話をします。
Perlというのは、1986年に誕生したプログラミング言語です。Rubyよりだいぶ上ですね。7年ぐらい。Rubyが誕生した1993年に、Perl5.0というバージョンがリリースされました。
Perl5.0は画期的なリリースで、オブジェクト指向機能が追加されたり、モジュールシステムがだいぶ改善されました。パフォーマンスも改善されたのでPerl5.0は、すごくエポックメイキングなリリースでした。
Perl5.0が出たのは1993年で、2023年で30年になります。おめでとうございます。なんですが、じゃあ2023年の現在、Perlのバージョンはどうなっていると思いますか？ 10？
Perl5.38なんですね。つまり30年間メジャーリリースが行われていないということですね。正直なところ、若い人たちはPerlというプログラミング言語を使ったり勉強したりしたことがないんじゃないかな。歴史の教科書に出てくるイメージだったりするんじゃないかと思うんですけども。
Perlのコミュニティ自身も、この点についてはだいぶ危惧していたんですね。2000年のことになります。当時の「The Perl Conference」の出席者は何千人もいて、Perlの人気を表すカンファレンスだったんですが、そのカンファレンスで「Perlの未来は、どうなるか？」という開発者のミーティングがあって、その時に、ある1人の開発者が出てきて、コーヒーカップを手に取って壁に投げつけたっていいますね。
「私たち、こんなことをしていてはいけないんだ」と言うんですよ。「このまま停滞していると、コミュニティが離れていってしまう」と。それで、コミュニティ全体として「なにもかもやり直して新しいPerlを作りましょう」という話になったんですね。
そこで、RFC、Request for Commentsというかたちで、「将来のPerlはどうなったらいいと思いますか？」「どういう新しい機能や斬新なアイデアを取り込んだらいいと思いますか？」「何を直したらいいと思いますか？」と、コミュニティから募集したんですね。
そうしたらコミュニティ全体から、ものすごく画期的なアイデアも含めて、361個の提案がされたそうです。当時はPerl5だったので、その提案をまとめてPerl6という言語を作りましょうという話になったんですね、新しいバージョンを作りましょうという話になったんですね。
これはすばらしい、今までの問題を全部解決した理想のPerlができるに違いないと思ったんですね。でも今言いましたよね、Perlのバージョン、いくつ？ 6でしたっけ？ 6じゃないんですね。5.38なんですね。つまり、Perl6は登場しなかったんですよ。
何が起きたかというと、2015年に、Perl6はRakuという名前……なんか日本っぽい名前ですね。Rakuという名前に変わりました。違う言語になったんですね。
じゃあ、2015年から8年経った現在、Rakuというプログラミング言語を知っている人はどのぐらいいるかというと、残念ながらほとんどいないんですね。
よそのコミュニティなので悪口を言うかたちになってしまうと困るんですが、正直言うと、あまり成功したという感じではないんですよね。
ここから、私たちは教訓を学ぶことができると思うんですね。コミュニティが停滞するとまずいということをPerlコミュニティはよく理解していて、私たちにもそれは適用されるということですね。
Perlコミュニティで、カップを投げて、「こんなんじゃ駄目だ」と言った人の言葉がこれですね。
「We are ピー（スライドでは「f**ed」） unless we can come up with something that will excite the community, because everyone's getting bored and going off and doing other things」。
「私たちは、なにかコミュニティをエキサイトさせるような新しいことをしないと、コミュニティ全体として駄目になってしまう」と。「なぜなら、みんな退屈してしまって、コミュニティから離れて違うことをしてしまうからだ。違う言語のほうに行ってしまうからだ」というふうなことを言ったわけでですね、これが2000年のことです。
これは慧眼だなと思うんですね。オープンソースソフトウェアにとって、退屈であるとか、停滞であるとかは、最大の敵なんですね。これは、前の「RubyWorld Conference」のキーノートでも言ったことがあるのですが、オープンソースソフトウェアだけではなく、モチベーションによってドライブされているすべてのプロジェクトにとって、退屈は敵だと思うんですね。
コミュニティには、強い拘束力がないんですよ。特にオープンソースコミュニティ。例えば会社とか雇用関係とか雇用契約とか、あるいは給料を払うなど、お金による関係みたいなものがあるのは、なかなか辞めにくい。強い結束力がある。
オープンソースコミュニティにはそういうのがないんですね。「私はRubyコミュニティに入っているから給料もらいます」という人は、いないんですね。ごくまれに、Rubyを開発することで給料をもらっている人はいますが、それにしたって、コミュニティに雇われているわけではないんですよね。
「Second System Syndrome」には気をつける
それを考えると、退屈しないように動き続ける必要がある。オープンソースソフトウェアは、動き続ける必要があります。あるいは、モチベーションによってドライブされるすべてのプロジェクトは、前進し続ける必要があるんですね。
さらに言うと、オープンソースのコミュニティは非常に大事なので、コミュニティを惹きつけるなにかが必要なんですね。
それが1つの教訓ですね。
Perl6からもう1つ学ぶことができる教訓は、「Second System Syndrome」、第2システム症候群。これが学ぶことができる教訓だと思うんですね。
なにか物がうまくいかなくなった時、なにか新しいことを始めましょうと、今までの土台を捨てて同じようなものを全部作り直して、それによって目的を達成しよう、みたいな気持ちになるわけですね。これは自然な感情だと思います。
それによって、私たちが今感じているすべての問題をいっぺんに解決しようと思うんですね。こういうのをSecond System Syndromeと言います。
こういうスクラップ＆ビルド、なにもかもすべて捨ててしまって新しく作り直そうというのは、みんな考えることではあります。世の中のシステムやプログラミング言語も含めて、まったく新しいバージョンを作りましょう、やり直しましょう、みたいなことを言いたくなるケースはたくさんありますが、うまくいったことはほとんどないんですね。
だからスクラップ＆ビルドというのは、システムに関しては実は悪いアイデアなんですね。そうではなくて、段階的に進歩、進化していく必要があるんですね。
2000年代初期、Rubyもスクラップ＆ビルドを計画していた
実はRubyも同じようなことを思ったことがあります。2000年代の初期ですね。だからPerl6が活発に開発されていた頃ですね、Perlの影響力が非常に強かったので、Rubyも同じようなことをしようかなと思ったんですね。
Rubyも今まで歴史的な事情でいろいろしがらみがあって、デザイン的にうまくいかなかったところをみんな捨てちゃって、すばらしいRubyを作りましょう、みたいなことを私自身も考えたことがあったんですね。
アメリカの「RubyConf」のキーノートを毎年話しているのですが、2003年のキーノートにRuby2という単語が登場しています。
Ruby2というのは、Perl6と同じように、Rubyがこれまで持っていた悪い点であるとか足りない点であるとかを全部やり直して、Virtual Machineも書き直します、コンパイラも書き直します、ライブラリも書き直します、言語仕様もだいぶ大幅に変更しますと。
それによってすばらしい理想のRubyを作ろうという計画を当時、まだ何もしていなかったので妄想をしていたんですね。
それで、Perl6と同じようにみなさんから「もし、Rubyをしがらみなく直すとするならばどういうところを直したいと思いますか？」と募集したことがあったんですね。
私は記録するのがすごく苦手なので、実際にいくつのRFCを受け取ったかをもうすでに憶えていないんですけど（笑）。
ルーズで、いろいろなものを管理するのがすごく苦手なので、そのうちにだんだん面倒くさくなってきて「全部最初からやり直すのは良くないかもしれないな」と思って、結局Perl6のアイデアをやめちゃったんですね。
でもこの私のルーズさと面倒くさがりというのは、Rubyコミュニティにとっては最大のラッキーだったんじゃないかなと思うんですね。
私がもし、Perlを作ったコミュニティの人たちと同じぐらい真面目で熱意があってやる気があって、物事を管理するのも得意で、きちんと記録する人だったら、今頃Rubyはなくなっていたかもしれないんですね。
いやぁ、面倒くさがりで良かったと思うことはあまりないんですけど（笑）、この時ばかりは本当に良かったなと思います。
そこで、なにもかも捨てて書き換え直すのはやめて、部分的に改善していくことで良くしていきましょうということで、Virtual Machineなどを書き換えたRuby1.9が登場したのが2007年になります。
Ruby1.9では、Virtual Machine、そこにいる笹田さん（笹田耕一氏）が書いてくださった「YARV」という名前のVirtual Machineに置き換えました。これによってパフォーマンスが随分高速になりました。3倍から50倍と当時言っていたような気がします。3倍でも大したもんですが、50倍ってものすごいですよね。
それから、Ruby1.8までのRubyは、日本人が作った日本人のためのプログラミング言語みたいな傾向が強かったので、ASCIIですね。英語、Shift_JIS、EUC-JP、それからUnicode、UTF-8という、この4つのエンコーディングしか扱うことができなかったんですね。
ですが、その時にエンコーディングという機能そのものを導入しました。そんなにあるのかっていう感じですけど（笑）、今は百九十いくつかのエンコーディングを、扱えるようになっています。
2003年時点では、まだUnicodeがどうなるかわからなかったんですが、2023年の現在、ほとんどのインターネットで流通する文字情報はUnicodeとかUTF-8になってしまったので、もしかしたら無駄な努力だったかもしれないなと思うところもなきにしもあらずです。でもですね、このような変更をしました。
誰にも言わなかったんですが、Ruby2のアイデアを捨てて良かったなとかみしめながら、Rubyを作り始めてちょうど20年のタイミングの2013年にRuby2.0をリリースしました。
継続的にやってきて良かったなと思いながら、例えば、Keyword Argumentを入れたり、Refinementという機能を入れたり、誰も知らないんですけど、私個人的にお気に入りのModule#prependという機能もですね、入れたのがRuby2.0です。
Ruby2.0の時点で、私が昔から欲しいなと思っていた機能の6割ぐらいが実装できたので、だいぶ満足できてはいますね。
2020年にこの場所で、「東京オリンピックの年に、Ruby3.0を出します」と発表した覚えがあります。東京オリンピックのほうがずれるとは誰も思わなかったんですよ（笑）。
Rubyは、ずれることなく2020年にリリースされました。Keyword Argumentの改善が行われて、より良いKeyword Argumentになりました。それから、パターンマッチングですね。昔から欲しかった機能を実装しました。
JITですね。Just-In-Timeコンパイラといって、ネイティブコードにコンパイルすることによってRubyを高速化する機能は（バージョン）2.6ぐらいから入っていたのですが、実際にプロダクションとして使えるようにJITが入りました。
それから、Heap Compactionという機能も入りました。こういう機能が入ったRuby3.0が出て、これで私が昔から欲しいなと思っていた機能の9割ぐらいの実装ができたんじゃないかなと思っています。
Rubyを今後どうするかについて考えていかないといけない
Ruby1.9からRuby2.0までが、だいたい5、6年、7年ですね。Ruby2.0からRuby3.0までが7年ぐらいですよね。そうすると、メジャーな変更までだいたい7年周期ということが観測できるので、それに従うとRuby3.0が出た7年後の2027年にRuby4.0が（出る）。本当？
（会場笑）
もう1つですね。Rubyのバージョンって毎年リリースされているんですね。Ruby3.1、3.2。2023年12月に3.3が出る予定なんですが、なにか特別な事情がない限り、毎年毎年リリースされているんですね。
もう1つは、これは私のわがままなんですが、Rubyのバージョン番号って1桁と決めているんですよ。Perlのほうはね、5.38みたいな、2桁になっているんです。アルファベット順に、辞書順にソートすると、1.0の次が1.1で、その次が1.10とかで並ぶことがあって、嫌なんですよね（笑）。1桁にしようと言っています。
こうやって1桁ずつ伸ばしていくと、2029年に3.9が出るんですよ。3.9の次、何が出るか。今3.10を出したくないと言いましたよね。そうすると、4.0にならざるを得ないかなと思って、2030年までにはなんとかしないといけないという。
何が起きるかはわかりません。先ほども言いましたが、欲しいものがだいたいできていて、私が昔から欲しいなと思っていてまだ入っていない機能は、パッケージシステムなんですね。それをデザインできたら、4.0が出てもいいかなと思っているところです。
もう1つはですね、司会の方にも言われちゃったんですけど（笑）、15年経ってだいぶ歳を取ってきたので、後継ぎを考える……例えば、PHPという言語は、だいぶ前から委員会制度というかたちで開発するようになりました。
勝手にライバル呼ばわりしているPythonは、2019年、4年ぐらい前に、最初に作ったグイド・ヴァンロッサムさんという人が引退されたんですね。「その後どうすんの？」と心配して見ていたのですが、5人のSteering Committeeという、方向性を決めるための委員みたいなものがあって、その1つの合議で決めていくらしいですね。
「その5人はどうやって決めるの？」といったら、毎年の「PyCon」で投票で決めるらしいです。民主的なんだけれど、それ、言語に本当に通用するのかなと心配になるところもあります。
そういうところも含めて、Rubyが今後どうなるかについて、4年だか7年だかわかりませんが、その間に考えないといけないなと思っています。
（次回へつづく）
