about blog projects contact

The Cogwheel Blog

# In Defense of Perl... ## ...and why predictions of its death are greatly exaggerated I had envisioned posting a brief entry on a few neat SQL tricks I have come to use more frequently before my thoughts drifted to drafting some initial pedagogical notes on my early impressions of Go, having tinkered with the language recently. Then, all of a sudden, I was hit (as were many, I'm sure) with that now famous (to some - *infamous*) *Stack Overflow* post on the most disliked programming languages (see [here](https://stackoverflow.blog/2017/10/31/disliked-programming-languages/) as a reference). *Refreshing* was my initial reaction to the article title, although it seemed a trivial academic exercise to me to simply turn the very many "most liked" programming language articles on their heads to come up with what would ostensibly be the same conclusions. However, it would appear the author made use of a more original approach of collating tags in the *Developer Story* profiles of members wherein an actual indication of 'dislike' can be registered for languages with which one prefers not to work. Very quickly, I surmised that Python would be among the most loved programming languages while simultaneously getting the feeling (with a sinking heart, it must be said) that the very likely candidate for most unliked (dare I say 'despised'?) would be...Perl. Sure enough, a quick glance at the results confirmed these thoughts - and I doubt there is a great mystery as to *why*. This survey comes at an interesting juncture for me personally, which is why I felt compelled to pen my two cents on the matter, thus squeezing out the other candidate topics I had envisioned penning here for posterity. ## Perl in the Back-End (computing, that is) Coming as I do from a scientific computing background, the mainstay of my early concerns in development had to do with conducting quantitatively-oriented research (in particular the development of trading strategies on Wall Street). In that world, there were no 'front-ends' to speak of and the processing of data in the most efficient way possible was of paramount importance (yes, just as it is in every other field making use of computer science but with even higher trade-off barriers favoring computation over aesthetic/other choices). To this end, many used relatively lower-level languages such as C/C++ or specialized statistical packages like R or SAS. In my case, I was made to adopt MATLAB by one of my former employers and I fell in love with it immediately - captivated as I was by both its speed and ease of use. Thrust into working in \*nix environments, I very quickly came to realize that in order to do anything with the data outside our own worlds - or to work with data to bring into our little computing corners (silos in which we developed the money-making recipe secrets to trading) - tools or applications of some sort would be needed. Sure, shell scripts existed for this option and I personally could go a long way using the ancillary capabilities of MATLAB but I quickly came to realize that for data engineering in the back-end there was one pervasive and very versatile tool. That tool was Perl. Sure, I realized that, but did I *like* it? I distinctly remember my initial reaction being: *What an odd, ugly language is this?* Nevertheless, there was part of me that was attracted to its cryptic qualities - enamored as I was by the old-school hardliners who preferred assembly and considered 'C' to be high level or the ultra-compact *A Programming Language* which for some might as well require an enigma machine to [read](http://archive.vector.org.uk/art10003130) - witness: <pre class="snippet"> Calculating Primes in A (APL): </pre> ![apl_snippet](/static/assets/img/blog/2017-10-31-perl/apl.png) ##### (*[More on APL here](http://www.users.cloud9.net/~bradmcc/APL.html)*) With that as my fire, I took to it and learned it and have been using it for well over 5 years now. In the process, I have overcome the enigmatic syntax and have come to appreciate Perl for its utility in doing the things I believe it to be particularly good at, namely: extracting, transforming, and manipulating/loading large datasets into, out of, and between data pipelines (basically any data engineer's requirements/responsibilities). ## Along comes Python In the meantime, particularly during my transition toward developer-only roles, I started coding in Python. While I have been at this for a similar timeframe, it was mostly off-and-on until a few years ago but has come to be my go-to language for accomplishing a lot of the tasks I tackle today. As with so many others, any reservations I might have had about adopting Python melted away after just a few hours of dabbling in it. The underlying reason, I am sure, is the same for me as it was for others - the beauty, simplicity, and yes, it must be said, *legibility* of the language made adopting it a no-brainer. I have found it to be particularly useful for object oriented programming, being made for it straight out of the gate, unlike Perl 5.x which offers awkward constructs for this, and for web development for which its ecosystem seems second to none across the stack, be it web server considerations or HTTP requests or the sheer number of frameworks available for its use, both back-end and front-end. As a result, I have a more-than-passing familiarity working in both languages, which just so happen to dominate the opposite ends of the likability spectrum in the said survey. I am by no means unique in this respect, of course, but nevertheless felt I might have some informed opinions to proffer on the subject of their comparison, which I do below. At the moment, I am philosophically agnostic on the diametrically opposing procedural viewpoints of each language, namely that with Python: <pre class="snippet"> There should be one and only one way of doing something. </pre> versus Perl's take: <pre class="snippet"> There's more than one way to do that. </pre> I see the arguments for and against each philosophy, but believe that's a disquisition best left for another date. Instead, I do have some strongly held opinions about specific characteristics of each language. The observations I offer below are from my experience alone and may well be unscientific and anecdotal. Nevertheless, I feel there is some value in offering them up for analysis. ## Features in favor of Perl over Python Leaving aside "legibility"-related issues (the use of quotes will become more apparent in my note below), there are several areas in which I find Perl to be an obvious choice over Python. ### Speed For one thing, among its *interpreted* peers, Perl is quite fast. Moreover, it also appears to operate at *acceptably-low* orders of magnitude slower than compiled languages like C or Go. When compared with Python, where speed concerns have dogged the latter ever since it's introduction, it's a no-contest. On the speed issue, it turns out I'm not alone and that it's not just a "feeling" I have, but others have attested to this issue, for instance [here](https://news.ycombinator.com/item?id=8626131). Indeed, the benchmarks page referenced appears to have several intriguing comparisons between Perl and other languages in which Perl 5.x is listed as outperforming Python 3.x on most benchmarks (see: [this](http://benchmarksgame.alioth.debian.org/u64q/perl.html)). (I should make clear I am no expert on benchmarking CPU clock speeds, and the like but do tremendously appreciate the work of others in this field). Some of this *might* be related to Perl's mysterious hash speed which appears to act geometrically faster than those of other languages (based on anecdotal observations of mine which have since been borne out by colleagues). For such a fundamentally important datatype, that's of huge importance (if there is indeed any truth to this empirical observation). ### System-native Secondly, Perl is more native/closer to the shell (e.g. bash). For instance, the core Perl distribution comes pre-packaged with features like native regex support and the very standard CPAN modules like POSIX make features like this (besides shell-based directory operations) a clear win for Perl over having to import these functionalities in Python from external modules (whether part of the standard library or not). If you're coming from a Linux background and working in the bash shell, this is yet another advantage in Perl's favor, in my opinion. ### Better RDBMS interfaces From a traditional RDBMS point-of-view, the adapter/driver modules developed for Perl seem to be well-seasoned and weather-tested. They are stable and sport expansive functionality for a wide range of use case scenarios, especially the usual suspects of SQLite, PostgreSQL, and MySQL. From my experience, I have found Python-MySQL integration to be awkward, a critical blow in my view as this is a key RDBMS for which a plethora of modules should have already been developed. To be fair, my experience working with PostgreSQL databases in Python-driven applications has been quite smooth thanks to the psycog2 module. It's also important to give credit to Python's dominance in the ecosystem of NoSQL databases and Object Relational Mapping (ORM) approaches in recent years (e.g. SQLAlchemy) for which Python interactions run quite smoothly (as though tailor-made, in a sense). However, in the relational database world where preserving data integrity in the backend is critical and best achieved through an RDBMS, I find Perl to be a clear winner over Python with its battle-hardened DBI module and driver packages like DBD for MySQL. (On a sidenote, I think it's also worth expressing the view that there comes a point when the NoSQL and ORM approaches need to stop being used by SQL- fearing developers as excuses to avoid writing efficient queries/stored procedures as it appears to me they so often are now). ### Weak type flexibility If you're just starting out, Python's strongly-typed approach imposes good discipline (and fosters good programming habits) without which beginner bugs in type-mixing could well lead to seemingly intractable bugs downstream. If you've been developing for a while, however, you're either not likely to make these mistakes and/or be aware of their possible presence and may well find the additional discipline to be a nuisance. I prefer Perl's weakly typed approach to Python's strongly typed, for this reason. Nothing scientific, just a preference (note that I generally run Perl using the strict and warnings pragmas so a bug along these lines is likely to be honed in on fairly quickly, regardless). With these fundamental characteristics out of the way, on more idiosyncratic and wholly unscientific issues, the following is a random list of qualities which cause to me to prefer programming in Perl over Python: #### Variable checking While not the most widespread task, checking if a variable exists or is defined is a fairly rudimentary and ordinary task and testing for it in a language should be likewise straightforward. In Perl, this is how one could do this: <pre class="snippet"> if (defined($var)) { print "it's defined"; } else { print "not defined"; } </pre> The Python equivalent is: <pre class="snippet"> try: var except NameError: print "not defined" else: print "defined" </pre> Do I like Python's added control-of-flow measures? Sure I do. But for a task which should really be as straightforward as this I find Perl's approach to be more elegant (though it hardly tries to be anything at all). Using Perl's ternary operator would make it even more so (see next). #### Ternary operators With conditional statements being such a fundamental programming construct and feature of languages, I feel that being afforded some flexibility on these offers tremendous advantages. Perl's ternary operators are very welcome in this respect. Let's take a generic comparison in Perl parlance as follows: <pre class="snippet"> if ( $var1 > $var2 ) { func1(); } else { func2(); } </pre> The ternary equivalent of this could be written as follows in Perl: <pre class="snippet"> $var1 > $var2 ? func1() : func2(); </pre> Ternary operators in Python are called *conditional expressions* for which the equivalent of the above would be: <pre class="snippet"> func1() if $var1 > $var2 else func2() </pre> Not quite the same thing, feeling-wise. Talk about awkward, Perl's ternary syntax here seems more readable to me than does Python's. #### White-space freedom I tremendously appreciate Python's clean syntax and, like others, do prefer it over many other languages. However, given its indentation rules (which though annoying at first, help with discipline with regard to both style and code organization) I sometimes find myself missing the liberated usage of whitespace in Perl (ignoring the small overhead it might introduce in interpreting and compiling a piece of code). For instance, I might define a Perl hash as follows: <pre class="snippet"> my %hashVar = ( 'NEST1' => { 'VAL1' => $val1 , 'VAL2' => $val2 , 'VAL3' => $val3 }, ... ); </pre> Such an entry would not necessarily be PEP8 compliant in Python but not only do I find such versatile use of whitespace to make code more legible (in *both* Perl and Python) it also serves a purpose. For instance, if I did not know for certain how many entries my hash variable was going to have, the format above, with a leading comma on each line, lends itself to adding more as I might please. *(Note: this is a style I shamelessly copied from a former supervisor of mine.* *I hope this person sees imitation to be the sincerest form of flattery).* ## Reasons to use Python instead of Perl ### Object-Oriented approach Perl was written with the intention to do what its acronym says: "Practical Extraction and Report Language" (leaving aside Larry Wall's jest that it stood for Pathologically Eclectic Rubbish Lister). While the veracity of either claim is subject to some debate, Perl nevertheless does perform text-based operations (hence extraction and reporting tasks) very well. As such, object-oriented programming was never intended as an original feature. When it was introduced in Perl 5, it was done so awkwardly. To make matters worse, Perl 6, which is meant to be a properly implemented version of OOP in Perl, has seen development and release delayed for over a decade. A little comparison here helps. In Perl, OOP goes a something along these lines where one declares an object in a dedicated package: <pre class="snippet"> package perlObj; sub new { my $class = shift; my ($quality1, $quality2) = @_; my $self = { q1 => $quality1, q2 => $quality2, }; return bless $self, $class; } </pre> and subsequently uses it as follows: <pre class="snippet"> my $objVar = perlObj->new('foo','bar'); </pre> Contrast this with Python's approach for declaration: <pre class="snippet"> class pythonObj(Object): [ or just: class pythonObj():] def __init__(self,quality1,quality2): self.quality1 = quality1 self.quality2 = quality2 </pre> and instantiate as follows: <pre class="snippet"> objVar = pythonObj() </pre> Clearly, Python's approach is far better than Perl 5's awkward system of blessed references. Also, it's just plain easier (and more intuitive) to reference object methods and attributes with a dot/period ('.'). Hands-down, Python wins in this respect. ### Web development ecosystem While Perl boasts a massive support network and a large number of external modules (see [CPAN](https://www.cpan.org/)), the sheer Python-based ecosystem in web development means it just makes plain common-sense to use Python for web development. While some Perl-based frameworks have emerged recently, there is no shortage (indeed, perhaps there is an *overabundance*) of Python packages, frameworks, and support out there tackling everything from CGI/web server protocols to front-end development utilities. Undoubtedly, Python's early forays into this field with the development of core modules such as BaseHTTPserver and SimpleHTTPServer no doubt gave it a firm foothold over its rivals in this regard. Early indications appeared to support Python's *requests* and *urllib* speed dominance over Perl's equivalent utilities, although it should be noted that Perl appears to have made up quite a bit of ground in that regard. Nevertheless, when it comes to the realm of the Web, it is difficult to argue a case in favor of Perl against Python, overall. While this list is shorter than some of the pros I listed for Perl, they are ***massive/heavy-hitters***. Just being far more of an Object-Oriented Programming language alone along with being better suited for the massive area of web application development are two huge plusses to prefer Python use over Perl in these areas. # Conclusion This last statement brings me to my conclusion which is that the world is rarely a binary place of black and white. It seems to me that being liked/disliked as a programming language masks a lot of things under the hood. From the foregoing above it seems abundantly clear to me that there are use-case scenarios for which Perl might be a better-suited language just as there are reasons to choose Python over Perl. A lot of my own work has thus far evolved along these lines. I have now come to use Python as standard practice for web-related work (like scraping) but defer to Perl to parse and load large data files piggybacking on the work Python has done. Similarly, I depend on Perl and its packages to load data into MySQL databases but tend generally to make use of such data (e.g. for analysis purposes) in Python. No real conflicts here, just a judicious use of each for where they perform best. ### Readability or Comprehension? All in all, I believe the overarching reason behind the "dislike" vote for Perl is the "code legibility" excuse which echoes the popular joke that: <pre class="snippet"> Perl's is the only code which looks the same before and after RSA encryption. </pre> Leaving aside such jocularity, I must say I have come to see this as a somewhat tired refrain. Code legibility is certainly an important part of programming and every developer knows what a headache it can be to read other people's code, even when in the same language. Putting aside stylistic concerns, however, I take the view that it's not so much *legibility* that's the issue with Perl code, it's more to do with *comprehension*. That nuance might seem pedantic to some, but I would argue that it's a vital difference because it puts the spotlight on the big white elephant in the room that no one seems to want to touch upon - namely: are developers rejecting Perl because they find it harder to "read" or because they haven't gone through the hoops to really *comprehend* it? If it's the latter, then I would argue this is a poor excuse to reject a language not only because this is behavior which should be eschewed over the long term (leaving aside the notion of programmer laziness, do we really want to foster a tradition in which we don't rise to any new challenges because it requires too much effort from our brains to understand something?) but also because it sacrifices advantages which Perl might otherwise have on offer for us. Indeed, this amounts to rejecting Perl out of something akin to *caprice*. Here's an (albeit shaky) syllogism in this regard: while many of us might well have gravitated to the mac and cheeses at dinner as kids, our parents did not push us to eat our veggies for nothing. Similarly, making the effort to truly learn/comprehend Perl may well yield fruits in excess of what one might have otherwise expected. In concluding, I think it's helpful to point out that many (including some Perl monks themselves) are surprised that Perl 5.x is still around (and not only is it around, it's alive and kicking). The adoption of Perl 6.x is bound to be very slow-going (just as with its release) but with better OOP support it may well be a force to be reckoned with, yet. All in all, disliking Perl a large number of developers today might be (how's that for ternary-style phrasing?) but extrapolations from such readings to making predictions of its death are in my view greatly exaggerated.

-A. Ozan Akcin