2000 年、Perl 6 が始まった — 言語設計を公募したら 361 本集まった

前回の結論はこうだった。

根本的に変えたい。しかし Perl 5 は変えられない。ならば、別の言語を作るしかない。

今回は、その「別の言語を作る」という判断が実際に下された日の話だ。

割れたマグカップ

2000 年 7 月、Perl 5 Porters（開発者メーリングリスト）の会合でのことだ。

Jon Orwant — 当時 The Perl Journal の編集者で、O’Reilly 側の人物 — が、 議論の停滞に業を煮やしてコーヒーマグを壁に投げつけた、と伝えられている。

「このままでは Perl は死ぬ。何か劇的なことをしなければならない」

この場で Perl 6 を始めるという方向が決まった、というのが語り継がれている話だ。

ここは「伝えられている」と書く。 この逸話は広く語られているが、 マグの数も、正確な発言も、資料によって違う。 一次情報に近いのは当事者の後年のインタビューや講演であって、 その場の議事録があるわけではない。

ただ、この話が繰り返し語られる理由は分かる。 技術的な議論が行き詰まったとき、それを動かしたのが技術的な議論ではなかった、 という構図が鮮烈だからだ。

2000 年 7 月 19 日 — 発表

Larry Wall が The Perl Conference 4.0（TPC4、O’Reilly 主催）の 恒例講演「State of the Onion」で Perl 6 を発表した。

発表の骨子は、技術的な内容ではなかった。こうだ。

Perl 6 は、コミュニティが設計する。

2000 年としては、かなり急進的な宣言である。

当時の主要な言語はどれも、設計者か、少数の委員会か、企業が決めていた。 「言語の設計を公開のプロセスに開く」という試みには、前例がほとんど無かった。

そして Perl には、それをやる理由があった。 Perl 5 の問題点は、Larry Wall よりも使っている人の方がよく知っているはずだからだ。 毎日それに躓いている人が、世界中にいる。

RFC — 361 本

発表と同時に RFC（Request For Comments） の募集が始まった。 誰でも「Perl 6 はこうあるべき」という提案を書いて投稿できる。

• 期間: 2000 年 8 月〜9 月ごろ
• 提出数: 361 本
• 内容: 文法の細部から、型システム、OO の刷新、演算子の追加まで

361 という数は、この試みが動員としては成功したことを示している。 人は集まった。書いた。

公募が返してきたもの

そして 361 本を並べたとき、分かったことがある。

コミュニティは「何が嫌か」は正確に言える。しかし「全体としてどうあるべきか」は言えない。

具体的には、3 つの形で現れた。

1. 提案同士が矛盾する

ある RFC が「この構文をこう変えるべきだ」と言い、 別の RFC が同じ構文について逆の変更を要求する。 どちらも、書いた人の文脈では正しい。

2. 局所最適の集合であって、一貫した言語にはならない

361 本はそれぞれ、1 つの痛みに対する 1 つの処方だった。 全部足しても言語にはならない。言語は機能の集合ではなく、 機能同士の関係が一貫していることだからだ。

3. 「足したい」は多く、「削りたい」は少ない

これは公募という形式そのものが持つ偏りだと思う。

人は、自分が困ったことについては書く。 自分が使っていない機能が存在することについては、わざわざ書かない。

結果として、提案の総和は必ず言語を大きくする方向に働く。 Perl 5 の問題の一部は「大きすぎる」ことだったのに、である。

Larry Wall が何をしたか

ここが、この回でいちばん重要な部分だ。

Larry Wall は、361 本をそのまま採用する道を取らなかった。 かといって、無視したわけでもない。全部を読んで消化し、自分の責任で設計し直した。

その出力が Apocalypse（黙示録）と呼ばれる一連の設計文書である。 番号は『Programming Perl』（ラクダ本）の章に対応していて、 「ラクダ本の第 N 章にあたる部分を、Perl 6 ではどうするか」という構成になっている。 その体系については第 7 話で扱う。

重要なのは、RFC の役割が事後的に変わったことだ。

当初の位置づけ	実際に果たした役割
Perl 6 の設計案	Perl 5 の痛みの一覧
コミュニティが決める	コミュニティが問題を提出し、設計者が解く

そして、これは失敗ではない。361 本の RFC は、問題の一覧としては極めて有用だった。 Larry Wall 一人では、世界中の人が Perl 5 のどこで躓いているかを網羅できない。

つまり、こう言える。

公募が返してくるのは、解ではなく問題である。 そしてそれは、公募でしか集められないものだ。

現代の Rust RFC や Python PEP と比べると、違いがはっきりする。 あれらは既存の言語への個別の変更を扱い、決定権者がいるプロセスだ。 Perl 6 の RFC 募集は、白紙の言語について、決定権の所在も曖昧なまま行われた。 集まるものの性質が違うのは、当然といえば当然だった。

2000 年の見込みと、実際

発表時点で Perl 6 がどう見込まれていたかを書いておく。

2000 年の見込み	実際
数年で出る	最初の安定版まで 15 年（2015-12-25）
Perl 5 の後継	互換性のない別言語に
Perl 5 は 6 に置き換わる	Perl 5 は独自に進化を続け、2026 年も現役
名前は Perl 6	2019 年に Raku へ改名

この 4 行が、この連載の全部だと言ってもいい。 残りの 9 話は、この 4 行のそれぞれが「なぜそうなったか」を扱う。

なぜ 15 年かかったのか（予告）

「15 年」という数字は、怠慢や混乱の証拠として引かれることが多い。 この連載ではその読み方を取らない。スコープの問題として扱う。

理由は少なくとも 4 つあり、それぞれ別の回になる。

1. 設計が壮大すぎた（第 4 話）— grammar、MOP、並行モデル、漸進的型付けを全部入れた
2. 実装基盤の賭けを外した（第 6 話）— Parrot に長く投資し、最終的に使われなかった
3. 仕様が動き続けた（第 5・7 話）— 実装が仕様に追いつくと仕様が動く往復が長かった
4. 専任の担い手が薄かった — 主要人物の離脱が直接速度に響いた

次回はまず 1 つ目を見る。 Perl 6 が変えようとしたものを並べると、どれも言語 1 つ分の仕事だったという話だ。

---

次回（第 4 話）: 何を変えようとしたのか。 シジル不変性、grammar、多重ディスパッチ、メタ演算子、Junction、そして有理数。 0.1 + 0.2 == 0.3 が True になる言語の話をする。