Why Perl Was Born — 18 December 1987, Between awk and C
When Larry Wall released Perl 1.0, he was not known as a language designer. He was known for two tools: rn and patch. What happens when a linguist builds a language to fill the gap where awk is not enough and C is too much. And how, by Perl 4, the two constraints that would eventually require Perl 6 were already visible in miniature.
18 December 1987
Larry Wall posted Perl 1.0 to the Usenet newsgroup comp.sources.unix. That is the official birthday.
The Perl community still treats that date as such. Perl 5.10 was released on 18 December 2007 to mark the twentieth anniversary. Not a coincidence — they aimed for the day.
It is worth starting from a date because Perl is one of the rare languages whose birth is unambiguous. Most languages force you to pick a starting point: an internal project kickoff, a paper, a first commit. Perl has the day it was posted.
What Larry Wall Was Known For
At the time he released Perl 1.0, Larry Wall was not known as a language designer. He was known for two tools he had written.
- rn (1984) — a Usenet newsreader
- patch (1985) — a program that applies diffs
The second one matters. patch is still here, under the same name, on our machines today.
It sits underneath git apply and inside distribution build scripts.
A forty-year-old tool has survived with neither its name nor its job changed.
And the problem patch solved was: how do you get your changes into someone else’s code?
That idea runs in a straight line into Perl’s later culture. CPAN, modules, getting work done by assembling things other people wrote. Before he built a language, Larry Wall was building tools for dealing with other people’s code.
The Gap It Filled
Perl was born in a gap between existing tools: the space where a shell, sed, and awk are not enough, and C is too much.
| Tool | Good at | Missing |
|---|---|---|
| Shell | Gluing processes together | Complex data structures, real computation |
| sed | Line-oriented substitution | Branching, subroutines |
| awk | Field processing, associative arrays | File handling, process control, regex power |
| C | Everything | Verbosity, a compile step |
Larry Wall kept falling into this gap while generating reports. You start in awk, run out of road, and rewrite in C — or you build a monster of awk, shell and sed joined by pipes.
Perl’s official expansion, Practical Extraction and Report Language, records exactly that origin.
In keeping with the culture, there is also an officially sanctioned backronym:
Pathologically Eclectic Rubbish Lister
That both of these are official tells you most of what you need to know about this language.
What Happens When a Linguist Designs a Language
Larry Wall studied linguistics in graduate school. That shows up in Perl’s design in concrete ways.
Context
The same expression means different things depending on where it appears.
my @array = (1, 2, 3);
my $count = @array; # 3 — scalar context gives the element count
my ($first) = @array; # 1 — list context gives the first element
This is a natural-language idea. The same word changes meaning with its position in a sentence. As programming language design it is heterodox; the majority position is that if the same thing means something different, it should be a different thing.
Sigils
$, @, % work like part-of-speech markers: singular, plural, lookup table.
Looking at a variable name tells you what kind of thing it is.
Word Order
print "done" if $ok;
Postfix if, unless, and until carry over the word order of English subordinate clauses.
“Print done, if ok.” The order you write can match the order you think.
How to Judge This
It is Perl’s greatest distinguishing feature and the target of its harshest criticism.
The defence: programs are read and written by people, and if human language works this way, writing in that direction is more natural.
The criticism is equally clear. Context-dependence makes behaviour hard to predict. Having to track “what context am I in here” while reading is a real cognitive cost.
And from this series’ point of view there is one more thing worth noting. Some of these very decisions are what Perl 6 set out to change. The rule where a sigil shifts with context was inverted in Raku. Part 4 covers that.
Three Principles
Three design principles were articulated from the earliest days. All three carry over into Raku unchanged.
TMTOWTDI
There’s More Than One Way To Do It.
This stands in direct opposition to Python’s “there should be one obvious way to do it,” and it became the cultural fork between the two languages.
Raku pushes it further still: multiple spellings for the same operation,
both for and map, if available in prefix and postfix position.
Easy Things Easy, Hard Things Possible
Easy things should be easy, and hard things should be possible.
The idea is that the user pays for the language’s complexity only when they need it.
Raku’s gradual typing — annotations are optional, but they bite when written — is the direct descendant of this principle. It runs without them. It gets stricter with them.
A Language Should Be Like a Natural Language
As above.
From Perl 2 to Perl 4
| Version | When | What |
|---|---|---|
| Perl 1.0 | 1987-12-18 | First release |
| Perl 2 | 1988 | A stronger regex engine |
| Perl 3 | 1989 | Binary data. Relicensed under the GPL |
| Perl 4 | 1991 | In practice, “the version that matches the book” |
Perl 4 is a slightly odd entry. It was less a major language change than a marker for a book.
In 1991, O’Reilly published Programming Perl by Larry Wall and Randal L. Schwartz. A camel was on the cover, so it became “the Camel Book.” Perl 4 was positioned to match its contents, and stopped receiving updates at 4.036 (1993).
And from then on, the camel was Perl’s symbol.
There is a fact here that pays off later. The camel is the animal on an O’Reilly book cover, and O’Reilly holds the trademark. It is not a logo Perl can use freely.
So Perl 6 had a different mascot from the beginning: the butterfly, Camelia. One letter away from “camel” — continuity preserved, trademark problem avoided. The rename did not change the mascot. It comes back in part 10.
The Two Constraints Perl 4 Carried
This is the part of this instalment I most wanted to write.
By Perl 4, the same kind of problem that would later require Perl 6 was already happening, one scale smaller. There were two constraints.
1. Data structures could not nest
With no references, you could not directly write an array of arrays or a hash of hashes.
There were ways to fake multiple dimensions (concatenating keys, $a{$x,$y}), but they were fakes.
In other words, there was a ceiling on the shape of data Perl 4 could express.
2. There was only a global namespace
No package, no module as a unit.
Splitting a large program up and sharing it with other people was weak.
How These Two Were Solved
The answer was not “improve Perl 4.” In 1994, the interpreter was rewritten from scratch. That is Perl 5.
There is a pattern here.
A language’s fundamental constraints cannot be resolved by adding features. You end up rebuilding the implementation.
Perl 5 did that and succeeded. Compatibility was broadly preserved.
And in 2000, the same judgement was made a second time.
This time it was Perl 5’s own fundamental constraints — the sigil rules, bless-based OO,
argument passing through @_ — and again, the plan was to rebuild from scratch.
What was different is that this time compatibility could not be preserved. It took fifteen years, and at the end, the name changed.
That is the story this series goes on to tell.
Next (part 2): What Perl 5 and CPAN built. What went into the 1994 rewrite — and then, in 1995, something that did not exist in any language at the time.