Mainly Tech projects on Python and Electronic Design Automation.

Saturday, March 18, 2006

What's wrong with Perl

It can be a refreshing tonic of a language when you move to perl
from something like basic, C or Java.
Perl can do what tens of Unix tools such as sed and awk can do from
the shell, but with more flexibility and higher order data structures
such as the perl 'hash' or 'associative array'.
You can sit and evolve a perl one-liner of X hundred characters
that will find and process millions of lines from thousands of files
from within hundreds of directories.
When you want to know how to do something else there is The Camel
, either the book or that human store of Perl Knowledge on the next
floor, a few cubicles over.
Before long, you have amassed a large personal perl knowledge
base, and can tackle most of your tasks, without having to consult
The Camel. You become more confident in perl and start to code for
others in your team, and write scripts in files rather than one


Languages have moved on.

Do you use perl references? Happy with them? Do you know that you
can get all that power without all the reference-gymnastics. Indeed,
you can get more power as you are freed from the mundane “how
do I create and use a hash of hashes”, to “O.K. The data
naturally starts as a hash of hashes so...”

Perl subroutines. Even AWK, one of the Unix stalwart languages
that perl was created to supplant has named arguments to its
functions. The better scripting languages can do a lot better,
allowing you to pass two lists into a function as easily as passing
in two integers. Or to return three hashes just as simply.

The perl slogan “There is more than one way to do it”
is often cited as one of perls strengths, and used by many
perl-mongers as their reason to stick with it. But how many of you
actually mean the extended form: “There is more than one way to
do it, and mine is the best”, or, “There is more than one
way to do it, but you will use mine!”, or more likely: “There
is more than one way to do it, and I don't know yours”, or
“There is more than one way to do it, and you will learn
mine!”, or “There is more than one way to do it, but I
don't know how to find any of them in Camels index”.

Perl still has goto! (and in its most evil of forms too, the
computed goto: where you have to interpret the program in your head
to work out where the goto might jump to from the listing because the
goto target is the result of an expression).

So much of perl documentation reads like 1001 recipes for using
1001 features, without any central theme to shape them.

Being an engineer, I am trained in finding patterns and
extrapolation. It is much easier for me to learn a small set of
powerful rules with a straightforward way of combining them. Perl,
unfortunately has a large number of 'gotchas' that bite when you try
to venture out from the recipes and examples given.


If you know perl, and have a need for programs greater than a few
tens of lines of code, then you should invest a week or two of your
time learning a different dynamic language. In that time, put aside
your perl knowledge and try to not just use the other languages
syntax, but learn how things are naturally done in that language.
Nothing may beat the 'perl -p -i -e' one-liner, but proper function
parameters and strict typing may be better for your longer scripts.

If you are thinking of learning Perl then think twice. Perls
'sweat-spot' is much diminished as new dynamic languages have emerged
with a less tacky support for new methodologies and standards such as
object oriented programming, program maintenance, functional
programming, XML, multi-language programming, and programming on
multiple frameworks such as dot-net and the Java Virtual Machine.



  1. After the week or two to learn the language put aside another few months or years to port all the CPAN modules you could have used.

  2. I don't think you have come up with enough reasons to come to that conclusion. So what if it has goto? So does C! Even perl's documentation says the EXPR-form of goto is not recommended.

    reference: perldoc -f goto

  3. Contrast the Perl goto, which is a documented Perl statement, with the only available goto for Python, where it is not available as part of the language distribution and is clearly labelled as being written as an April fools joke, and not to be used.

  4. Just because it has a goto doesn't mean you have to use it. Writing good code is as much about programmer discipline as the language you use. I've never used/needed normal goto in perl in 7 years coding. Neither has the author of perl.

  5. In response to "Just because it has a goto ..."

    Maybe Perl should have taken the opportunity to remove at least the computed form of the goto over the years.
    If it is there, and no one should use it, then it should not be there!

    - Paddy.

  6. I use goto :) And im not ashamed of it... makes my code much simpler.... Instead of adding another layer of "if", goto simplifies my life.

    I think, though, that using more than 1 goto sentence per module is bad...

  7. Hi,
    With labelled loops and the last,redo, and next statements optionally taking a label, you can easily get out of nested scopes. goto is in the Perl language and so people like yourself use it rather than more structured programming norms, or the use of exception handling.

  8. Perl and goto: goto is a very valuable tool in Perl, but it's vastly misunderstood. You typically should NOT use goto directly. It's in the language as a tool for generated code.

    Most uses of goto in Perl are of the recommended form (goto &subroutine which invokes the subroutine without changing the parameter or calling stacks). This is used widely in internal modules for implementation of features such as autoloading.

    A few uses are the more traditional variety such as for error recovery. File::Copy used to do this in order to preserve the value of errno, though I'm not sure if it still does. These uses are carefully combed over by the Perl community and removed when they're not strictly essential for the code to work as designed.

    What saddens me is that there are languages out there that fail to provide such tools, forcing their users to wedge those extraordinary cases into some other approach. goto is very often the wrong tool for high level programming, but sometimes they're exactly the right tool, and that's when the language should not get in your way and force you to do something other than what's correct.

  9. Hi Aaron,
    Maybe the plain goto should be reserved for 'advanced' courses, but why have the computed goto? That's just a maintenance problem every time it is used!

    - Paddy.

  10. paddy,

    As with the plain labeled form of goto, this is intended mostly for generated code (remember that one of Perl's first and most important uses was as a back-end for an awk-to-perl translator, and it continues to be used in many environments where code is generated by perl in perl).

    For example, in Pugs::Runtime::Regex (the Regex runtime for the Perl 6 on Perl 5 engine) you will find the line:

    optional( sub{ goto $alt } ),

    Even if you know Perl as well as I do, that line should make you stop and think fairly hard about what's going on here. However, what this code is doing is generating Perl code that implements Perl 6 regexes. That's exactly where this sort of technique makes sense, and where it *should* be used to reduce the complexity of the GENERATING code (at the cost of complexity in the generated code, which is not what needs to be maintained over the long term).

  11. Hi again Aaron,
    it seems that Perl with its large feature set should then package them better. Some features such as all forms of the goto should be much harder to get at - signalling to the potential user that its not standard to use them, and to the book writers and tutors, that they can omit them or confine them to appendices. Similarly Perls support of objects should have been extended and standardized to make it easy to wrap C++ objects as Perl objects, and to ensure that older forms of Perl OO are not taught ....

    ... I guess a lot of my concerns are being addressed in Perl6 but if Perl6 does preserve these 'lower level' features such as goto and subs without named parameter lists then they should be much, much harder to get at - it reminds me of BBC Basic ( which allowed you to put assembler in your Basic program, but didn't pretend that assembler was on an equal footing with the Basic.

    - Paddy.

  12. "it seems that Perl with its large feature set should then package them better. Some features such as all forms of the goto should be much harder to get at"

    That's a matter of language design aesthetics, and you're welcome to the opinion that some language features should be difficult to use. Perl does not conform to this aesthetic, so you're likely to continue not to like it. *shrug*

    To each his own. If you like some other language, please proceed to use it. Part of embracing the broad range of possible techniques is accepting that some people don't.

  13. I'll just add this snippet:

  14. Urg... the post-comment system on this blog just ate my comment.

    To summarize: the link you point to has a terrible answer. The answer to the actual question is: Perl uses the rules of numeric conversion defined by the ANSI C library function, strtod, which will throw away anything at and following the first character which is not part of a valid number. Thus "0 but true" is a string which represents a valid numeric value, "0".

    All the stuff about the CONVENTIONAL use of "0 but true" in perl is entirely off-topic for the question.

    That being said, you're trying too hard. If you don't like Perl, you don't like Perl. That's enough. If you want everyone else in the world to use the language you do like, then write lots of useful code in it, and they will come.

    It's really that simple.



Subscribe Now: google

Add to Google Reader or Homepage

Go deh too!

Blog Archive