I must be turning into a grumpy old man.
In this months issue of Communications of the ACM an article was included entitled Integrating Web Sites and Databases. It wasn't in fact, about any such topic, but was instead a comparison of various web technologies.
The article brought up all the classic myths about Perl: hard to read, slow, not-compiled, etc, etc. To top it all off the article included a piece of Perl code that did not compile, and didn't mention Perl at all, but kept banging on about something called PERL
So, I put on my grumpy old man hat, and wrote a letter:
As a Perl programmer of some ability I found myself with no small degree
of distaste left in my mouth having read the article 'Integrating Web
Sites and Databases' in the September 2002 issue of CACM (Volume 45
While Perl does have shortcuts available in the language, any competent
engineer writing software for long-term use would be foolish to use
them. Perl also has many idioms, but these are no more complex to a
Perl programmer than the idioms one may find in any other language to a
programmer of that language.
One will find with careful study that Macromedia's Cold Fusion, ASP.NET,
JSP, and Java Servlets also use CGI, which is a documented calling
convention that glues the web to programmatic functionality and makes no
mention of implementation. Furthermore, Perl does not embed "HTML
outputs" in its code. A programmer may, but Perl does not. To help
remove this suggested problem, one can use many 3rd party templating
systems available on CPAN (the Template Toolkit being a single example).
Web developers in general -- and serious Perl programmers specifically
-- have long moved away from the idea of mixing business and
presentation logic together, and the thought of "HTML page designers"
adding code as needed is disturbing.
The problem of invoking a copy of the script each time is also
described, which of course wastes web server resources. When Perl is
used in tandem with Apache the mod_perl module serves to alleviate this
issue by embedding the Perl compiler inside the server. Much like JSP,
the Perl code is compiled the first time the server needs it, and then
remains cached inside the system until it is required again. Although
this requires that applications are Apache specific, developments are
taking place that allow multi-tiered object-oriented applications to be
written for multiple server-types (Apache, Zeus, IIS, etc).
As a matter of course, I should also point out that Perl is not written
PERL. For matters regarding the language it is a proper noun, and
should be written 'Perl'. If you wish to refer to the implementation
(distribution, binary, etc) you can neglect the proper-noun
capitalization, and write it simply as 'perl'.
Perl struggles with a poor reputation precisely because of un-researched
statements propagated in articles such as this. In order to espouse the
'best tool for the job' philosophy, it is important that you are aware
of the tool's capabilities. Another thing that Perl does have is a
strong online community that is often more than prepared to help answer
issues such as those presented in your article, provided of course, the
author is prepared to ask.
Finally, the Perl code in figure 3 fails to compile, lending even less
credibility to the article.
The reply felt like I was browsing slashdot:
Perl programmers seem thinner skinned than most?? Of course the Perl
program doesn't work. The third author on the paper made what he though
were minor editing changes that broke it (he doesn't program in Perl -
he also capitalized PERL). The fact it doesn't work in no way affects
the points made.
Where I work there are hundreds of Perl scripts used to maintain
software on thousands of computers. The problem with them is that no has
enforced "good" coding standards for these scripts and whenever the
person responsible for the script leaves for greener pastures, no one
can maintain them (at least without studying them for a lengthy period
of time during which lots of problems crop up throughout the system).
Perl is just another language - that encourages shortcuts far more than
To which I folllowed up with:
n Wed, 2002-09-11 at 14:41, Morrison, Charles M. wrote:
> Perl programmers seem thinner skinned than most?? Of course the Perl
As a programmer in general, I grow tired of seeing untrue statements
propagated again and again about one of the tools in my toolbox. To
find a misleading article about Perl in CACM was disappointing,
especially as in a periodical of such normal high quality one expects
more research to be carried out. As I mentioned in my earlier email the
Perl community has a high degree of skill, and would have been only to
happy to help provide the information required to make a fair comparison
of the technologies should you have asked.
> program doesn't work. The third author on the paper made what he though
> were minor editing changes that broke it (he doesn't program in Perl -
> he also capitalized PERL). The fact it doesn't work in no way affects
> the points made.
This is fine, and probably irrelevant -- it was largely an unfair
statement on my part and you are quite correct in that it doesn't affect
the points made. However...
> Where I work there are hundreds of Perl scripts used to maintain
> software on thousands of computers. The problem with them is that no has
> enforced "good" coding standards for these scripts and whenever the
> person responsible for the script leaves for greener pastures, no one
> can maintain them (at least without studying them for a lengthy period
> of time during which lots of problems crop up throughout the system).
No-one *enforces* highly maintainable code written in Smalltalk, C,
Scheme, or Java either. The issue you refer to is a programmer problem
rather than a software problem. I've worked with Perl for quite some
time now, and I've worked been handed workable code and unworkable
code. I have had the same experience with the languages listed above.
If you ask a poor Perl programmer to write code they will hand you poor
Perl code. If you ask a poor Perl programmer to maintain someone else's
poor Perl code, you have a doubly-aggravated situation. The same is true
of most programming languages. Perl's unfortunate situation is that it
is very easy for people to consider themselves fluent in Perl when the
reality is they are not -- its easy to program Perl in baby talk, but
that doesn't mean you should ship it. Despite all this, I fear this is a
fruitless argument, as most discussions along this vein about Perl do
tend to be.
> Perl is just another language - that encourages shortcuts far more than
Maybe so, but you fail to respond to the other, more important points
that make up the meat of my earlier critique. Throughout the article
there are comparisons made between Perl and other more domain-oriented
solutions that are not fair. For example, JSP is a solution to a
specific problem domain, written in Java. The Template Toolkit
available for Perl offers a very similar proposition. If you'd like to
have a web based system compiled and therefore faster and more scalable
then you can use mod_perl. There are also FastCGI implementations
available for Perl.
For the larger part of the article when talking about Perl you compare
apples with oranges, and then state in conclusion that oranges make a
poorer apple pie.
Forgive me if I came across as harsh, but people who use Perl on a
day-to-day basis have to deal with these sort of claims in many other
places. As a software professional it disappoints me to see the same
claims in what I consider to be the software professionals journal.
I suppose we'll see how the saga continues.