DEV Community

Cover image for On Venerable Technology--Perl, Part 1
Delon R. Newman
Delon R. Newman

Posted on • Updated on • Originally published at delonnewman.name

On Venerable Technology--Perl, Part 1

It seems these days that I often find myself in the position of one of the elder programmers in team settings. This is unsettling for a variety of reasons, one of the more obvious being that I’m just over 40, and one of the most troubling being that there’s still so much to learn. However, I do find that there’s some perspective that comes from being involved in the same industry for a while (27 years or so now—time waits for no one), and perspective, I’ve found, is always valuable. I often hear folks waxing nostalgic about PHP or the early days of JavaScript, but I hear very little about the wonder of a language that PHP and JavaScript, warts
and all, could never have come to be without. That language is Perl. To understand its significance we have to do a little time traveling, but before
we do that let’s talk a little about programming.

Programming is a deep and strange art (not to start debates about whether programming is an art, for me there is no debate, programming is an art if for no other reason than because Knuth said so, and if you don’t know who Knuth is please get back to your studies). It’s linguistic, it’s mathematical, for many it’s mechanical. Now that teaching programming is becoming more of a focus there’s starting to be some actual science on the subject and it seems according to at least one study in our brains’ opinion it’s none of the above.

Yet, each programming language, out of necessity, takes a stand on the matter. To C (old venerable C) programming is about helping the human communicate with the machine in a way that is portable (in the late 60’s sense of the word “portable”). To Lisp (my dear old friend) programming is a mathematical art, that is about the the creative artist communicating with themself (and others) then and only then with the machine. For COBOL programming is about getting the job done and in way that looks like English so hopefully, with a silent prayer to the saints, somebody who comes behind this guy will be able to understand his code.

Most other languages take one of these positions or some combination thereof. Perl, however, takes a view of programming that is uniquely its own. Yet, peridoxically, one of it’s most unique features is putting no effort into being unique. Rather all of its effort was thrown entirely in the opposite direction. That is, cannibalizing every good idea from every place else starting first with natural languages.

Please don’t misunderstand, Perl is not linguistic in the sense that COBOL and Basic and SQL are linguistic. These computer languages were linguistic in the shallow sense. Yes thanks to Chomsky, et al. they all have a formal grammar, and that formal grammar “looks” like English, but these languages only steal the appearance of natural languages. They lack deeper features that have a profound effect on the usability (the user interface) of language. Now the programmer (a bit older than myself) that was forced to sling Perl code at her Web 1.0 startup cries foul, “I know this guy didn’t bring up usability while talking about Perl”.

Yes, I said it, usability. Again, now there is actual science behind this and Larry Wall (the father of Perl) was trained in linguistics. Many of those features that make languages like Perl or APL look strange and alien actually make them more usable once you’ve learned them. The key is once you’ve learned them. Many of us who came to love Perl have had the experience of truly thinking in Perl (much the way we do in our native tongue) an experience I don’t think I’ve had in any other language since (it seems APL hackers report similar experiences). And ultimately that seems to have been a part of Perl’s struggle like Lisp and Smalltalk it’s a deep language, like C++ it’s a big language. It’s power was that it was also
easy to learn, that is, the basics were easy to learn, but the deeper parts that were necessary to know in order to understand it’s essential design and see how deeply coherent the language actually is was more like the process of having the code-as-data, “aha” from Lisp or the message passing, “aha” from Smalltalk, it took effort and that effort was only exerted by a relative few.

In a later article I’ll endeavor to illuminate those usability features. So for now, thank you for reading and in the meantime please enjoy these tasty links!

Top comments (0)