Monday, August 24, 2009

Archaic Perl

A couple of days ago I had to attend a vendor who came to offer their services for the development of a web application.
As one of the participants of the organization had to handle some unexpected event, I took the opportunity to start a small research during casual conversation: "What development tools do you use at company?". In an ideal world the answer would have been: "Perl", but they told me that they work mainly in Python, but can work in other environments, including Perl. After informing them that the organization prefer Perl for the development of our applications, and after a micro religious debate, one of them (Juan) concluded:
In the end anything that can be done in one language that can be done in the other, but Perl programming is just more archaic.
that nearly upset me, but given that the missing guy arrived and the important issue was the meeting, I remained calm.
Now in retrospect I wonder: what he meant by saying that Perl is archaic? Perhaps John was referring to Perl 1 (1987), which was a kind of Shell Script with grep, sed and awk included, he could even think  that until Perl 4 (1991, soon after Python 1.0), however the current age is Perl 5 (1994) and viewing the subject young age, I think that Juan couldn't find a word to describe the mythical defects of Perl, so he ended up using the wrong word.
If Perl is archaic, then probably the object-oriented and functional programming are too, however those are the two technologies with most momentum at the present, and given that Perl's own object system was copied from Python, I will assume he meant some of the following:
  1. Perl is ugly
  2. Perl is messy
  3. Perl is unreadable
  4. Perl is incomprehensible
I will briefly address these prejudices that have been widely circulated on the Internet and for which there is no real support, much less after the rebirth of Perl (which I will discuss in another article).

Perl is ugly

As this is a matter of taste, things which are ugly to some one may be very attractive to other. But assuming that Perl is one of the ugliest languages, it has features that make it a practial language to solve a lot of problems easily.
One of the features that make Perl syntax leaning (not necessarily ugly) are the sigils indicating the type of each variable, however this feature facilitates extensibility and allows the interpolation in strings, and when I say Perl is extensible I mean that we can intervene in the compilation process to change its original syntax, a very high level feature shared with few languages, and the basis of the domain specific languages (also called DSL) that are very useful and popular. Perl offers at least three different mechanisms to achieve this goal.
Another feature is the practical integration of regular expressions within the language, therefore making extensive use of them, unfortunately, these expressions are ugly no matter what language are you using.
Take for example the parsing of a specific instruction from LaTeX:


In Perl it would look something like:

if ( $latex =~ m/\\begin\{[az]+\}/ ) ...

In Python it would look like:

pattent = re.compile(r'\\begin\{[az]+\}')
if pattern.match(latex):

In fact neither is nice, but  Perl is really more succinct and easier to understand, and I will not show the hassle to use them from Java.
Finally there is the holy argument about coding style and all that nonsense about the compiler enforcing to write the code in a good style. I say this because even when I think you get used to "the right coding style", it is also true that sometimes this is a nuisance and gets in your way, and in such cases there is no remedy. Below there is an example of Python code hard to format because of inflexible language syntax.
When code requires a particular style, you should use formatting tools, for example I use indent for C, and perltidy for Perl, lately I write my Perl code in the following style:

perltidy -l=99 -sbl

No matter how I get code delivered or if I type it myself, because I can convert it into my standard style with a single command, even before saving it (I use vim).

Perl is messy

Languages are not messy, people are.
However, there are languages that have more features than others to organize a project, Perl provides several ways to organize the code to suit many needs, ranging from programming on a single line (command) to the construction of large and complex applications.
The language allows the creation of procedural modules with their own namespaces, which may even be organized into multiple files to be loaded "on demand", very enterprise, isn't it?.
While most languages only have a fixed way of handling objects, Perl has a basic object system that allows to implement OOP in many ways, like the language motto says: "there is more than one way to do it".
Perl avoids to force the programmer to follow a particular structure, whether it fits the needs of a specific program or not, otherwise it would be like Java.

Perl is unreadable

This is just a particular combination of the two myths that preceded it, but it is also argued that you can not read the code wrote after 15 min., and that may be good some times, because it allows you to write programs quickly even if they are dirty, after all nobody wants to design and document code following the principles of software engineering to understand the last program I wrote a few hours ago, only because I needed a hint on the character frequencies in a dozen files:

perl -MYAML -ne '$c{$_}++for split//;END{print Dump\%c}' data.txt

It is easier to write this again than trying to understand it, of course this is easy to make in Perl because it has some magical constructs, do not try something like this in another language, because your best scenario is to make it work, but I guarantee that it will be much longer and difficult.
But Perl also allows you to write nicer code if it were necessary:

use YAML;
use IO::File;
use strict;

my %counts;
my $fd = new IO::File $ARGV[0], "r";
while ( my $line = readline($fd) ) {
    for my $letter ( split( //, $line ) ) {
print YAML::Dump( \%counts )
I'm sure this is as easy to understand as Python or Ruby for a programmer, isn't it?. Then the issue is not if the Perl language is unreadable, but the motivation to write the program, and the programmers expertice to write code easily readable or maintainable even by less experienced colleagues.
Finally, the least of my worries while making the last example was formating the code, since my editor did most of that work automatically, but just in case, I used perltidy on it, for you to see how well it looks.

Perl is incomprehensible

For whom?, Japanese is incomprehensible to me, but I doubt that to be the case for most people living in Tokyo, Perl is equally incomprehensible to someone who is not trained to understand it. In the previous section I showed you that Perl code may be as clear as Java or Python counterparts.
Certainly there is a lot of Perl code that is virtually incomprehensible except for the language gurus, but that doesn't mean that the programs should be written that way.
The shorthand form that allows to obfuscate Perl code also makes perl not just an interpreter, but a very useful tool in the command line, also allowing the expression of the genious and expertise over the language. There are very few languages that allow yo do JAPHs as Perl.
The fallacy appears when people start saying things like: "Perl is evil because it allows those things", or my favorite: "It is impossible to write unreadable programs in Python", really?, lets see who understands this little program written in Python:

for n in range(12):
    exec("abcdefghijkl"[n]+"=lambda x=0,y=0: "+filter(
        lambda x:x not in "\n$\r","""(x*y#x/x!range(x,
d" % a(x,y#map(lambda y:i(x,y),h~#" ".join(j(x)#"\\n".
print l()
and I can find much nastier things written in Java, which means you can write bad and incomprehensible programs in any language, and probably rookies can do it only because they are naive.
However, full potential of the developers may not be unleashed unless the language provide the highest level abstraction mechanisms, and in this case languages like Java and PHP are pretty bad while Perl outperforms Python and Ruby easily, disqualifying any possibility to label Perl as archaic.
Perl can be as corporate as any other language, and mastering this language in an organization is an investment where the code can be used and reused in many ways: from systems administrators to developers, via the database managers etc., and in solutions ranging from simple command line operation to the development a corporate application.


  1. Fully agreed. There is no broken tool - only dead beat coders. And each tool has its use.

    But having said that, perl has many many uses. Sure it's not the solution to every problem, but for me it's the solution to 2/3 of my problems.

    For someone attacking a similar task, refusing to take advantages of perl features means having to suffer spending 3 times as much on a different language.

    Good if you are consulting. Not good if you want to go home early with the satisfaction of the job being done.

  2. This is really nuts. He used a vague word, and you took it to mean the most easily defeated arguments. You made your own strawman argument, with your own lame inferences.

    Perl is viewed as archaic because the *language* does not provide for namespace/class differentiation, meta-documentation, object type-primitives, inlined methods, traits, strongly type methods, boxing/unboxing, decent overloading, it doesn't run on any JITable JVM.... What people are left with is a solid time-tested core, that lacks a lot of stuff. This leaves them to rely on numerous modules on CPAN like Moose which, while awesome, occasionally randomly break and require maintenance. Worse-off Moose's penetration is rather small on CPAN, at best not even half of even today's CPAN contributions use it. Furthermore, the vast majority of older code remains without it, and with a community that is resistant to upgrade at the expense of execution speed, or compile time cost.

    With that said, maybe it is still better than python/ruby.

  3. I don't dislike Perl, but requiring the use of references to nest arrays and hashes is indeed archaic and awful.

  4. I agree with the previous statement of it not running on the jvm or .net and though this would have been a good idea. But, with that being said you can use modules to call java code and place a module in java to call perl code directly. As well as, using rpc,soap and web services to communication with diffirent apps within an enterprise enviroment. I am a perl newbie and use CPAN constantly. I am always amazed at some of the problems that can easily solved using CPAN and perl. Almost as much as Java or some other enterprise language. All this being said Perl is my first language I have looked at others Ruby,Java,C# as a second langauge and once I have learned slash master Moose I will look at Scala as a my second langauge for Enterprise programming using the JVM.

  5. Your regex is wrong. it should be /\\begin\{[a-z]+\}/

    /\\begin\{\w+\}/ might be more appropriate.