Why Raku (part 2) - Perl Magic
Published on Mar 24, 2024 by Tom Gracey.
Perl was really the first server side scripting language to become popular for building websites and web applications. Perl even predates PHP, which "began life as a simple little cgi wrapper written in Perl". During the 90's Perl popularity soared; companies were finding they could develop applications significantly faster and with fewer code lines than in C - which was great for their bottom line. Perl code rapidly took over the web, to the point where it was described as "the duct tape that holds the internet together".
Perl was so popular everyone was using it - from seasoned professional coders to rank amateurs and complete newbies. Because the Perl philosophy was centred around practicality (perhaps this is what the "P" in "Perl" stands for - depending who you ask), the tendency was for concise code simplifications to get added in to the core language for every set of instructions found to be commonly used. So for example when it was discovered that it was commonly needed to assign a value to a variable only if that variable had not already been defined
if ( ! defined $p ){ $p = 4; }
a shortcut was introduced:
$p //= 4; # assign 4 to $p only if $p is not already defined
When it became clear coders were dereferencing hash and array references just to obtain a single value
%hash = %$ref;
$var = $hash{ "value" };
a shortcut was introduced:
$var = $ref->{ "value" };
There are a lot of misunderstandings about Perl - in fact I would describe it as by far the most misunderstood language. These misunderstandings are of particular importance to my overall argument, so I will return to discuss how these arose in the next part of this series. One of the biggest misunderstandings is the fundamental philosophy of the language. Perl was not trying to be obscure, as many commentators maintain. Indeed why would the language have become so popular if it was deliberately "difficult to read"? Why would anyone have chosen it over C (which does not suffer this insult)? Nor was TIMTOWTDI ("there is more than one way to do it") an actual goal of the language - as is frequently claimed. In my opinion "TIMTOWTDI" more likely evolved organically as a trend on Perl forums - and as an example of "Perl monger" tongue-in-cheek humour - rather than being a premeditated design objective.
No the objective of the language was always to be *concise* - it was all about packing in code shortcuts such as the above so scripts could be written in less characters. TIMTOWTDI was a by-product of this philosophy, not an objective - with so many shortcuts available, there was inevitably "more than one way to do" most operations you could think of.
In Perl it is easy to perform multiple operations in a single line, and if used wisely this can result in a clean and functional elegance
print "Stripped digits $1 from id $id" if $id=~s/(d+)//;
This single line
- contains a conditional (the print statement only fires if $id contains numeric digits)
- strips the digits from $id (provided the conditional fires)
- populates the "magic variable" $1 with the stripped digits
- prints (sends to STDOUT) the text contained in the quotes with variables interpolated
Note that we don't need to mess around with "match objects" or any such nonsense - we get our match reference in only 2 characters ($1). This is not obscure or difficult to read - on the contrary it is simple and clear.
However, it is true that plenty of horrible messes were created using Perl. The combination of the high degree of programmer freedom it offered together with every coding rookie on the planet piling into it was bound to result in some gargantuan messes - and it did. I have personally spent many thousands of hours picking my way through some barely fathomable spaghetti heaps trying to make head or tail of the workflow.
In time these messes began to be held up as evidence that Perl was bad. The "obscure" and "unreadable" labels were gaining traction. But I would argue that these labels stemmed from immaturity and were never justified. This was a literal case of bad workmen blaming their tools. It was coders who made those messes, not Perl. Plenty of messes are made by kids with paint brushes - that doesn't mean paint brushes are bad and artists shouldn't use them. On the contrary, if you want a Monet-quality oil painting you won't get far restricting your artist to crayons and a colouring book.
But with the introduction of Python this is exactly what we did.
In the next installment of this series, I will explain how - in my opinion
- the success of Python was founded on false premises coupled with an aggressive anti-Perl propaganda campaign
- Python's restrictive philosophy results in uncomfortable functional deficiencies which are built into the language
- the adoption of Python has done more damage and caused more setbacks than any other shift in language usage
Maybe I will call the next installment "The Python Lie". That will upset a few people. Stay tuned!
