Christmas — 15 年後の最初の安定版、そしてリリースとは約束である

年を言わないジョーク

Perl 6 には長年のジョークがあった。

「Perl 6 はクリスマスに出る」

オチは、どの年のクリスマスかを言わないことである。

15 年のあいだ、このジョークは機能し続けた。 機能し続けたということは、出ていなかったということでもある。

2015 年 2 月、FOSDEM の基調講演で Larry Wall がこの年を指定した。 講演のタイトルは “Get Ready to Party!”。 2015 年のクリスマスに、Perl 6 を production ready として出す。

同年 10 月の開発版リリースのとき、彼はこう言っている。

昔からのジョークのとおり、Perl 6 はこのクリスマスに出ます。 ただし今回は、本気です。

2015 年 12 月 25 日 — Perl 6.c “Christmas”

出た。発表から 15 年 5 か月である。

何がリリースされたのか

ここは正確に書く必要がある。リリースされたのは、roast の凍結点である。

第 7 話で書いたとおり、Perl 6 の仕様の正はテストスイート roast にある。 「6.c」とは、2015 年 12 月時点の roast を凍結したものを指す。

処理系（Rakudo）はその前から動いていた。 Rakudo Star は 2010 年から配布されていたし、 実用的に Perl 6 を書いている人は既にいた。

では、何が変わったのか。

リリースとは機能ではなく約束である

ここが、この回でいちばん書きたい点だ。

6.c のリリースで技術的に増えた機能は、ほとんど無い。 増えたのは約束である。

ここから先、6.c の roast が通る挙動は壊さない。

これが安定版リリースの意味だ。

• それまで: 仕様は動く。今日書いたコードが来月動かなくなりうる
• それ以降: 6.c を宣言したコードは、将来の Rakudo でも動く

第 4 話で書いた use v6.c; というバージョンプラグマが、この約束の実装である。 1 つの処理系が複数の言語版を同時にサポートする。

ここに、この連載の 9 つ目の型がある。

リリースとは機能の追加ではなく、変えないという約束の開始である。

だから「もっと機能が揃ってから出せばよかった」という批判は的を外している。 約束を始めるのが遅れれば遅れるほど、約束が始まらない期間が伸びるだけだからだ。

そして裏を返せば、約束を始めた瞬間から、後方互換性という重荷が始まる。 第 2 話で Perl 5 について書いたことが、Perl 6 にも適用され始めた。

15 年とは何だったのか

ここで一度、この連載の前半をまとめておきたい。 第 3 話で「理由は 4 つある」と予告したものである。

1. 設計が壮大すぎた（第 4 話）

シジル不変性、grammar、多重ディスパッチ、メタ演算子、Junction、遅延評価、 漸進的型付け、MOP、有理数の数値タワー。 どれか 1 つでも言語 1 つ分の仕事で、しかも互いに独立ではなかった。

2. 実装基盤の賭けを外した（第 6 話）

Parrot に長く投資し、最終的に使われなかった。 汎用 VM の前提（複数言語が乗る）が成立しなかった。 2013 年に MoarVM へ移り、そこから 2 年半で 6.c に届いている。 つまり、基盤が決まってからは速かった。

3. 仕様が動き続けた（第 5・7 話）

実装が仕様に追いつくと仕様が動く、という往復が長かった。 これ自体は健全な機構である（Pugs が始めたものだ）。 しかしその往復が VM 層まで届くと、コストの桁が変わる。

4. 専任の担い手が薄かった

Pugs の減速がその最も鮮明な例だった。1 人の離脱が、全体の速度を変えた。

まとめると

怠慢でも混乱でもない。スコープと、基盤選定の 1 回の失敗と、人員の薄さである。

そしてこの 4 つのうち、2 番目だけが「やり直せた」ものだった。 MoarVM への移行は 2013 年で、6.c は 2015 年。 基盤が決まってからの 2 年半が、この言語の実質的な完成期間だったとも言える。

何を得て、何を失ったか

出たこと自体は達成である。15 年かけて、やろうとしたことは概ね実現した。 第 4 話で並べた 9 項目は、ほぼ全部が動く言語として存在している。

しかし、この 15 年で失ったものもある。正直に書く。

失ったもの 1 — 評判

「Perl 6 は遅い」という評価は、主に Parrot 時代のものだった（第 6 話）。 基盤が入れ替わっても、評判は基盤より長く生きた。

失ったもの 2 — 待っていた人

2000 年に「数年で出る」と聞いた人たちは、15 年のあいだに他の言語へ移った。 Ruby on Rails が出て、Python が科学計算で伸びて、 JavaScript がサーバ側にも来て、Go や Rust が現れた。

Perl 6 が出たとき、それを待っていた人の多くは、もう待っていなかった。

失ったもの 3 — Perl 5 との関係

これが最も重い。

Perl 5 は 15 年間、待っていなかった（第 2 話・第 4 話）。 Moose が出て、5.10 が出て、年次リリース体制になり、独自に進化していた。

そして外から見ると、**「6 が出ているのに 5 を使っている」**という奇妙な状態が 15 年続いていた。Perl 5 のユーザは、存在しない後継に追い立てられ続けた。

この 15 年で最も損をしたのは、Perl 6 ではなく Perl 5 だったかもしれない。

6.d “Diwali”（2018 年）

2 番目の言語バージョンが 2018 年に出る。名前は Diwali — ヒンドゥーの灯明祭である。

Christmas、Diwali と、版の名前が文化を跨いでいるのは意識的だろう。 2026 年 9 月時点では 6.d が既定であり、6.e が策定中である（第 12 話で扱う）。

そして、名前の問題が残った

6.c が出たことで、Perl 6 は「完成していない言語」ではなくなった。 技術的な問いには答えが出た。

しかし、名前の問題は何も解決していなかった。

• Perl 5 は依然として「6 が出たのに 5」と見られる
• Perl 6 は依然として「Perl の新バージョン」として紹介される
• Perl 5 は依然としてバージョン番号を進められない

そして重要なことに、6.c が出たことで、初めて改名が可能になった。

未完成のまま名前を変えれば「失敗したから逃げた」と読まれる。 完成した言語が名前を変えるのは、独立の宣言になる。

改名が 2019 年である理由の一部は、ここにある。

---

次回（第 9 話）: 名前が技術的負債になるとき。 「Perl 6」という名前は、19 年間、検証されていない主張を運び続けた。 三方が損をする構造と、名前が負債になる条件の話をする。