When a Name Becomes Technical Debt — "Perl 6" Carried an Unverified Claim for Nineteen Years

This instalment is written so that people who do not know Perl can read it. The subject is Perl 6, but the problem itself is not specific to a language.

The Name Was Correct When It Was Chosen

Start here.

When Larry Wall gave it the name “Perl 6” in July 2000, the name was correct.

As part 3 covered, at the moment of announcement Perl 6 really was conceived as Perl 5’s successor. Breaking all compatibility was not a settled intention; there were proposals for migration tooling to bridge the gap. “The next version of Perl” accurately described the plan at the time.

And then the thing changed.

• Compatibility became unkeepable as the design progressed (part 4)
• It took fifteen years (part 8)
• Perl 5 evolved independently in the meantime (part 2)

The name did not change.

Here is this series’ tenth pattern.

A name freezes the claim made at the moment of naming. The thing changes; the name does not update itself.

That is what “a name becoming technical debt” actually is. Nobody chose a wrong name. A correct name stopped being correct.

And like debt, left alone, it accrues interest.

The Structure — All Three Parties Lose

What the name “Perl 6” carried was two things that do not coexist:

• The fact: Perl 6 is a language incompatible with Perl 5
• What the name claims: Perl 6 is the next version of Perl 5

Three losses follow at once. Everyone losing is the distinctive feature of this structure.

1. Perl 5’s Loss — “A Finished Language”

The version number appears stuck at 5.

It reads as “you’re still on 5 when 6 is out” — as legacy that could not migrate.

In reality Perl 5 shipped every year and kept gaining features (part 2). But from the outside it looked like a language whose version had not moved in fifteen years.

This is real damage. Adoption decisions, hiring, what to learn — all of it is judged on “is this language alive?” This is what part 8’s closing line was pointing at: the biggest loser may have been Perl 5.

2. Perl 6’s Loss — “An Unfinished Perl”

It does not get evaluated as its own language.

• “When is Perl 6 coming out?” for fifteen years — and people kept asking after 2015
• Its distinctive features, like grammars and the concurrency model, never become the subject of evaluation. Framed as “the new version of Perl,” its comparison class becomes Perl 5
• People who dislike Perl exclude Perl 6 without looking

The word “Perl” brings both the positive and the negative inheritance. Perl 6 did receive the positive side too — history, community, culture — so this is not simple victimhood. But the mix was not something it could choose.

3. The Version Number Was Blocked

Perl 5 could not advance to its next major version, because “6” was taken.

This is the clearest loss of the three. And the Perl 7 proposal appearing immediately after the rename confirms it.

In June 2020, then-pumpking Sawyer X announced Perl 7: “Perl 5.32’s syntax with modern defaults turned on from the start” — a proposal to enable use strict and friends by default.

That is a change of defaults, not new features. And the precondition that made it possible was the rename freeing up “6.”

(For accuracy: Perl 7 was deferred in 2021 and has not shipped as of September 2026. The current release is Perl 5.44. This is easy to get wrong, so state it plainly.)

Why It Sat for Nineteen Years

The problem had been raised since the 2000s. The rename came in 2019. Why so long?

Reason	Detail
A rename looks like defeat	Fear of being read as “Perl 6 failed, so they changed the name”
The founder chose the name	A sense that a name given by Larry Wall was not the community’s to change
Nineteen years of assets	Documentation, URLs, repositories, module names all contain “perl6”
No agreement on a replacement	Many candidate names, no consensus
You cannot move before it is finished	Renaming while unfinished looks like running away

The last point was decisive. Because 6.c shipped in 2015 and made it a finished language, the 2019 rename could be executed as independence rather than defeat.

That is why part 8 ended the way it did:

Changing the name while unfinished reads as fleeing a failure. A finished language changing its name is a declaration of independence.

The Conditions Under Which a Name Becomes Debt

Now the generalisation. The Perl 6 case is valuable because the debt is measurable — in the form of nineteen years of needing the same explanation every time.

The condition can be stated:

When a name contains an unverified claim about the thing it names, that name is debt.

“Perl 6” contained the claim “this is the next version of Perl 5.” That claim stopped being true, but the name repeats it every single time.

So the explanation cost is permanent. One explanation does not settle it. Every article, every conference talk, every new person — the same explanation again.

The Same Shape Elsewhere

The structure recurs far outside language design.

What got put in the name	When it becomes debt
A version number (Foo 2)	You cannot ship the next one — or people expect 3 to follow
The implementation language (RubyGems, node-*)	You cannot change the implementation without the name lying
An organisation (AcmeDB)	Transfers, spin-offs and acquisitions pull the name out of true
A relative position (next-*, new-*, *2.0)	You cannot be “next” forever
An intended use (a tool named for images that also handles video)	The name narrows as the use widens

What they share is that the name implicitly promises not “this is so” but “this will continue to be so.”

And as part 8 put it, a promise constrains change.

A release is not the addition of features; it is the beginning of a commitment not to change.

A name has the same structure. Except that with a name, the promise was never explicitly declared — the reader infers it. So you break a promise you never remember making.

What the Rename Did Not Solve

In fairness: the rename solved only part of the problem.

Recognition did not increase

If anything, a situation arose where people who know “Perl 6” do not know “Raku.” When you abandon a name, you abandon the recognition attached to it.

Search was fragmented

Everything written before 2019 says “Perl 6.” Searching for Raku does not lead you to the good older material.

This is heavier than it sounds. Nineteen years of accumulation became invisible from the new name. (The migration document in the next instalment chooses 301 redirects for exactly this reason — to minimise it.)

The rename itself became the news

The headline “Perl 6 renamed to Raku” was also read as “Perl 6 failed, so they renamed it.” Part 8 argued that they could rename because it was finished — but without that context, it just looks like a surrender.

Was It Worth Doing Anyway?

The answer can be: lay out what was achieved and what was not, and let the reader decide. That is rule 3 of this series’ writing rules.

But one thing can be stated as fact.

Without the rename, the losses would not have stopped. For nineteen years, this name generated interest daily. Perl 5 looking like a dead language, and Perl 6 looking unfinished, were not things that would shrink if left alone.

A rename is a measure to stop further loss. It does not recover the preceding nineteen years. Those two should not be confused.

Next time, we look at what that rename actually consisted of as work. When you change a name you have used for nineteen years, what do you count?

---

Next (part 10): Path to Raku. Reading the published migration document. File extensions, environment variables, the .perl method, IRC channels, hashtags, and 301 redirects. A rename is the work of counting every place the name is embedded.