Buddy Burden

This is part 8 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at the ongoing evolution of Perl.

Last week I closed with the observation that it’s difficult for other languages to evolve beyond Perl because Perl keeps evolving.  And it does: it evolves at quite a bewildering pace, compared to other languages.  Take a look at the evolution of C, for instance.  Oh, sure: we can talk about C++, and C#, and D, and even Java, as evolutions of C, but they are different languages, far more so than Perl 6 is a different language than Perl 5.  If you look at the C language itself, it’s changed several times throughout its history, but the C we have today doesn’t look that different from the original K&R.  It’s no more different than, say, American English is to British English.¹

On the other hand, look at the evolution of Perl.  We don’t even have to go to the Perl 5/Perl 6 schism;² we can look at the difference between Perl 4 and Perl 5.  Remember, my first Perl experience was with Perl 4: no objects, and having to put & in front of all your function calls.  The difference between Perl 4 and Perl 5 is more like the difference between modern English and that of Shakespearean times: oh, sure, you still know it’s the same language, but there are plenty of phrases that are just plain nonsensical, and lots of others that sound contorted or bizarre.  And we needn’t even stop there.  If you were to compare Perl 4 to modern Perl 5, with its new operators such as // and ~~, new keywords such as say, state, and given, new object syntax using Moose and possibly MooseX::Declare or Moops, new exception syntax using TryCatch or even Try::Tiny, maybe throw in some even more radical syntax extensions such as Dancer or Bread::Board::Declare or Future, now you’re looking at modern English vs something like the Canterbury Tales, which as you may know sounds like this:

Lordynges, ther is in Yorkshire, as I gesse,
A mersshy contree called Holdernesse,
In which ther wente a lymytour aboute,
To preche, and eek to begge, it so no doute.
And so bifel that on a day this frere
Hadde preched at a chirche in his manere,
And specially, aboven every thyng,
Excited he the peple in his prechyng
To trentals, and to yeve, for Goddes sake,
Wherwith men myghte hooly houses make,
Ther as divine servyce is honoured,
Nat ther as it is wasted and devoured,
Ne ther it nedeth nat for to be yive,
As to possessioners, that mowen lyve,
Thanked be God, in wele and habundaunce.

Which seems like it almost makes sense, if only you could figure out how a day could be so frere that it made everything else so bifel that Chaucer felt the need to point it out.  Until you realize that “bifel” really means “befell,” and “frere” really means “friar,” and not only has the vocabulary changed, but even the grammar, to the point where your intuition about what things mean is pretty well borked.  Certain constructs become more (or less) permissive; certain structures become more (or less) common.  The same things happen in Perl.  Perl evolves in more radical ways than other languages (it seems to me) primarily due to its similarity to a natural language, which allows it to mimic the evolutionary patterns of natural languages.

And this radical evolution is a part of Perl’s heritage; moreover, it’s a part of Perl’s identity.  This is why I’m always so surprised to hear people railing against such evolution.  Perhaps I shouldn’t be; people whine about the evolution of English all the time, even though without it we’d all still be prechyng and beggyng and lyvyng like Chaucer up there.  I mentioned once before that languages must either evolve or die, and it’s just as true of natural languages as it is of computer languages.  There was a time when splitting infinitives was verboten, just as there was a time before that when it wasn’t,³ and now it’s okay again.  There’s no point in railing against the change.  The language is going to keep transforming, whether you like it or not.  The only part that’s in question is whether you’ll end up sounding like the cool guy who always knows the latest lingo or like a grumpy old man yelling at kids to keep off his lawn.

Who remembers pseudohashes?  Pseudohashes were one of those experimental features that Perl tried, and rejected.  To be fair, the particular implementation of the concept was pretty bad.  The fact that the first element of the array was where the hash keys were stored meant that it was stupidly difficult to use them in foreach loops or in simple maps or greps.  Worse, as the man page told us, it was slowing down normal array and hash access.  Of course, the man page also told us that the feature would be implemented differently in future versions, but instead it disappeared altogether.  I have had people tell me that this is proof that pseudohashes were a mistake.  Except that’s not right at all.  The concept of pseudohashes was perfectly sound, and I’m actually planning to release a module which will act a bit like pseudohashes (based on the same object that is being discussed in that TT2 thread), which I find I miss quite often these days.  But it won’t make element 0 unusable, and it certainly won’t impact the performance of normal arrays and hashes.  So will it still be a bad idea?

Now we have the same problem with smartmatching.  I’m sure there are some examples of actual people having actual problems with the smartmatch operator, but you can’t find such things with a Google search these days, because all you turn up are theoretical people having theoretical problems with it, which are used to explain why it’s now marked “experimental.” In fact, it seems to me (from my thoroughly unscientific research) that we’ve spent a hell of a lot more words explaining why it’s “experimental” than we ever did complaining about actual problems it caused.  Now we’re in the situation where the number #1 reason people don’t use smartmatch in their code has nothing to do with any actual problems it causes and is solely because of the word “experimental.” After all, as one of my coworkers put it: “I definitely feel more confident when I don’t see the word ‘experimental’ in production code.”⁴  And there we are trying to put the brakes on evolution yet again.

Except that never works.  “Evolve or die” isn’t just a cool quote to make things sound more dramatic.⁵  History shows us that, whether we’re talking about species, companies, music, literature, or language, things that survive evolve, and contrapositively things that don’t evolve, don’t survive.  Change is the only universal constant, as the old saying goes.⁶  So either Perl is going to continue evolving, as it always has, or else we will manage to halt its evolution sufficiently that it will stagnate and die.  Given those options, it sort of boggles my mind that people want to battle evolution.  I feel about it the same way I feel about people fighting against equality: above and beyond any considerations of the merits of the particular question at hand, it seems like you have to realize that every single instance of people blocking progress, throughout history, has eventually failed.  Oh, sure, sometimes it seems like those efforts are succeeding, but it’s always only temporary.⁷  In the end, progress always wins.  Why fight it?

I suppose there’s an argument to be made that people have different opinions as to what constitutes blocking progress vs what can be construed as attempting to guide progress.  Because I believe that progress is self-correcting, but only because people actively work to make it so.  So I do support any efforts of people to attempt to get progress back on track when it strays off into dead ends or unproductive side channels.  And I’m sure that sometimes what I call trying to forestall progress altogether, other people see as legitimate attempts to make sure things are progressing in the right way.  Sometimes I can see that.  Other times, I just don’t get it.

So I’m always going to see new features, new syntaxes, new paradigms as positive, because they represent evolution to me.  I may quibble over the particular implementation, of course, or even the exact syntactical structure that will best represent the new hotness—I think those are constructive conversations to have—but you’re not likely to see me advocating for trying to squash a new feature altogether.  Even if I don’t particularly care for it, or can never see myself using it, I’m still going to want to see my language evolve and grow and become.  With my first three primary languages, I essentially evolved by trading up to a new language every 5 years or so.  And the reason that Perl is where I’ve stopped (for the past 17 years) is that I don’t need to evolve by switching languages any more.  I just wait for Perl to evolve, again, and then I’m the one who has to keep up.  That’s one of the things I love about Perl.

Next week I want to delve a little bit into another of my favorite things about Perl: its incomparable ability to Get Shit Done.