In 2000, Perl 6 Began — Crowdsource a Language Design and You Get 361 Proposals

Last time ended here:

We want to change it fundamentally. But Perl 5 cannot be changed. Therefore we must build a different language.

This time: the day that judgement was actually made.

A Smashed Mug

July 2000, at a meeting of Perl 5 Porters — the developers’ mailing list.

Jon Orwant, then editor of The Perl Journal and an O’Reilly figure, is said to have lost patience with the stalled discussion and thrown a coffee mug at the wall.

“Perl is going to die unless we do something drastic.”

The story goes that the decision to start Perl 6 came out of that room.

Note the “is said to.” The anecdote is widely repeated, but the number of mugs and the exact words differ between sources. The closest things to primary evidence are later interviews and talks by the people present; there are no minutes.

Still, it is clear why the story keeps getting retold. A technical discussion had stalled, and what moved it was not a technical argument. The shape of that is vivid.

19 July 2000 — The Announcement

Larry Wall announced Perl 6 in his customary “State of the Onion” talk at The Perl Conference 4.0 (TPC4, run by O’Reilly).

The core of the announcement was not technical. It was this:

Perl 6 will be designed by the community.

For 2000, that was a fairly radical declaration.

Every major language of the era was decided by a designer, a small committee, or a company. There was almost no precedent for opening a language’s design to a public process.

And Perl had a reason to try. The problems with Perl 5 were, presumably, better known to the people using it than to Larry Wall. People were tripping over them every day, all over the world.

The RFCs — 361 of Them

A call for RFCs (Requests For Comments) opened alongside the announcement. Anyone could write up a proposal for how Perl 6 ought to be.

• Window: roughly August–September 2000
• Submissions: 361
• Range: syntax details, type systems, an OO overhaul, new operators

The number 361 shows the experiment succeeded as mobilisation. People turned up. They wrote.

What the Call for Proposals Returned

And when you lay 361 proposals side by side, something becomes clear.

A community can say precisely what it dislikes. It cannot say what the whole should be.

This showed up in three forms.

1. Proposals contradict each other

One RFC says a piece of syntax should change this way; another asks for the opposite change to the same syntax. Both are right in the context of whoever wrote them.

2. A set of local optima does not add up to a language

Each of the 361 was one remedy for one pain. Summing them does not produce a language, because a language is not a set of features — it is the features being consistent with each other.

3. “Add this” is common; “remove that” is rare

I think this is a bias inherent in the format itself.

People write about what has hurt them. Nobody goes out of their way to write about features they simply never use.

So the sum of proposals always pushes toward a larger language — even though part of Perl 5’s problem was that it was too large.

What Larry Wall Did

This is the most important part of this instalment.

He did not adopt the 361 as written. Nor did he ignore them. He read all of them, digested them, and redesigned the language on his own authority.

The output was the series of design documents called the Apocalypses. They are numbered to match the chapters of Programming Perl — the Camel Book — so that each answers “what happens to chapter N in Perl 6.” Part 7 covers that document system.

What matters here is that the role of the RFCs changed after the fact.

Originally framed as	What they actually did
Design proposals for Perl 6	An inventory of Perl 5’s pain
The community decides	The community submits problems; the designer solves them

And this is not a failure. As an inventory of problems, the 361 RFCs were extremely useful. Larry Wall alone could never have enumerated where everyone in the world was tripping over Perl 5.

Which gives us this:

What a call for proposals returns is not a solution but a problem statement. And a problem statement is exactly the thing you cannot gather any other way.

Put next to a modern Rust RFC or Python PEP, the difference is sharp. Those handle individual changes to an existing language, and they have a decision-maker. Perl 6’s call was about a blank-slate language, with the locus of authority left vague. It is unsurprising that what came back was different in kind.

What Was Expected in 2000, and What Happened

Worth writing down how Perl 6 was expected to go at the moment of announcement.

Expected in 2000	What happened
Out in a few years	Fifteen years to the first stable release (2015-12-25)
Perl 5’s successor	An incompatible, separate language
Perl 5 gets replaced by 6	Perl 5 kept evolving and is still current in 2026
The name is Perl 6	Renamed to Raku in 2019

Those four lines are arguably this entire series. The remaining nine parts take each of them and ask why.

Why It Took Fifteen Years (Preview)

The number “fifteen” usually gets cited as evidence of sloth or chaos. This series does not read it that way. It treats it as a problem of scope.

There are at least four reasons, and each gets its own instalment.

1. The design was too ambitious (part 4) — grammars, a MOP, a concurrency model, gradual typing, all at once
2. The bet on an implementation substrate did not pay off (part 6) — years invested in Parrot, ultimately unused
3. The specification kept moving (parts 5 and 7) — a long back-and-forth where implementation catches up and the spec shifts
4. There were few full-time hands — the departure of key people hit velocity directly

Next time we take the first of these. Lay out what Perl 6 set out to change, and every item is a language’s worth of work.

---

Next (part 4): What it set out to change. Sigil invariance, grammars, multiple dispatch, meta-operators, junctions — and rationals. A language where 0.1 + 0.2 == 0.3 is True.