# 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>
##### (*[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.
