[oclug] Why Perl is a Bad Language
doneill at linuxcare.com
Thu Feb 22 15:34:51 EST 2001
On Thu, 22 Feb 2001, Francis Pinteric wrote:
> Yawn! Ok, quoting St. Augustine is not reasoned. Ok, let's quote
> Larry Wahl himself: "Perl is a mess. It's a mess because the problem
> space is also a mess." By problem space he's talking here
> specifically about webpage design and other internet stuff.
( It's "Wall", not "Wahl" )
> There are complaints about whether or not Perl is really the tool for
> XML (http://www.xml.com/pub/2000/10/11/perlxml/index.html).
What that article boils down to is "Right now, people who use Perl aren't
really people who use XML, so let's fix it". It's certainly not a
condemnation of the Perl language by any means.
Personally, I've used Perl with XML in rapid-prototyping situations with
> In the end it's easier to use shell scripting to do ordinary things.
> Perl was designed as a specific tool to read USENET lists because he
> decided (quite rightly) that the shell scripts in an of themselves
> were too slow to do what he wanted. However, I've found that now the
> reverse has happened: people are using Perl to do things where shell
> scripting is the correct solution.
This boils down to "Use the right tool for the job". Perl isn't always
the right tool. Neither is C, or C++ or Java or Bash scripting, or ....
How does this make Perl a bad language? It doesn't, no more than any
> Now, to counter Larry Wahl's assertion that because the problem space
> is a mess so should the solution, I give you zope and why it's in
> This from a python beginner.
Again, this still doesn't explain why Perl is such a horrible programming
language. Perl and Python both have their strengths and weaknesses, and
that's what this article points out.
> This might not seem important to most people on this list, but for
> those of us who do and have worked in industries where software
> errors can be very expensive or cause loss of life, this is
> important. So, in this area, being able to prove that a piece of
> software does what's it's supposed to do is vital.
Correctness proofs for any nontrivial piece of software are difficult, if
not impossible, no matter what the language.
[ snip incorrect and misleading bit on NP-Completeness ]
Anyway, let's get back to the real meat and potatoes of the issue -- does
Perl suck? For some things, yes, and for others, no. And for many
things, it's a matter of personal opinion and interpretation. Here's
Perl is a great language for rapid development, quick one-offs, and
prototyping. It's good for small to medium software projects,
particularly ones where you can leverage CPAN and avoid reinventing the
wheel. CPAN is a godsend for code reuse -- Perl is far ahead of any other
programming language in this respect. The ease and simplicity of reusing
Perl packages is unmatched. (Yes, other languages can do similar things,
but none of them have a central repository of code to reuse). For text
processing, again, Perl wins out. Perl is also wonderfully portable -- if
there's a Perl interpreter for the platform, your code will most likely
work, provided you aren't using platform-specific features.
Perl isn't so good at being readable and understandable by beginners.
Some of the constructs are obscure, and it's very easy to get lost. More
than a passing familiarity with C and shell utils are needed. It's
certainly not a good first programming language. It's also easy to write
unmaintainable code in Perl, though Perl is certainly not alone in this
regard. For performance-critical applications, or ones that require a
small memory footprint, Perl probably isn't a good idea either. Perl also
lacks a "clean" OO syntax, and some nice OO features, like interfaces and
private member variables and functions, making OO programming in Perl more
difficult than it should be.
The language also enforces very little in the way of policy. If you want
to implement your objects as an anonymous scalar, go right ahead. If you
want to format your code blocks all on one line, do it. This is both a
blessing and a curse, and at times, both.
Just my $0.02.
Dave O'Neill, Senior Linux Consultant
Linuxcare, Inc. tel: (613) 562-9949 fax: (613) 562-9700
doneill at linuxcare.com http://www.linuxcare.com/
Linuxcare. Putting open source to work.
More information about the OCLUG