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
Number 9).
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.
Sincerely,
James
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
most.
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
> most.
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.
Regards,
James.
I suppose we'll see how the saga continues.
Re:Well done that man
jordan on 2002-09-11T15:47:05
Agreed!
I particularly like this part:
- > Perl is just another language - that encourages shortcuts far more than
> most.
Maybe so, but you fail to respond to the other, more important points
that make up the meat of my earlier critique.
You don't take the bait in endlessly wrangling over whether Perl is inherently more or less maintainable than other languages. You covered that argument well in your earlier paragraphs and set it aside. It is a question that can only be decided with considered research into best practices, not by "I know that at where I work we have lots of Perl..." anecdotes,.
I think that if the "Perl unmaintainable" argument was approached this way, it would be found that the problems are with practices, not programming languages. Now, I do happen to believe that Perl does make possible the use of sloppy practices, but this is just a tradeoff. The straight-jacket languages that make these practices impossible also throw out a lot of other good things.
Anyone else find it ironic that the "third author" made minor changes that made the PERL [sic] not work because he doesn't know Perl? My guess is that a lot of the bad coding that goes on out there, including at the respondent's workplace, are people making changes who don't really know Perl and then using the result to criticize Perl as a language, much like they did in this article and the author does in his response to you.
who peer reviewed it and why the hell was it not even proof read or anybody in the perl community contacted.
How hard would it have been for the authors to actually consult any perl FAQ? It sounds an awful lot like they just rehashed crap like you find on CNET or ZDnet.
usually I find the C of the ACM useful if dry and over-engineered. But this is the first time I have heard of it publishing 3rd rate trash you'd expect in Internet Made Easy magazines.
I recently heard that they changed their editorial focus (less academia, more practicum). I saw a sampling what they've been printing over the last few years, and it looked like it might be time to reconsider a membership to the ACM.
But if they're publishing the kind of old, tired urban legends of computing that you're describing, it'll be another 10 years before I even consider rejoining the ACM.
Thanks for trying to set them straight. Hopefully, it'll help.
Re:CACM
james on 2002-09-11T18:17:14
But if they're publishing the kind of old, tired urban legends of computing that you're describing, it'll be another 10 years before I even consider rejoining the ACM.
For the most part I've been relatively happy with CACM this year. IMO CACM had about 8 good issues with 2 very good issues. Then again, what I like may not be what you like, etc, etc.
However, as you can probably tell, this article really got me going. OTOH, this article is written by academics for the Real World, so maybe that little nugget explains the blip.
