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 liners.
WAKE UP!
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.
Conclusion
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.
END.
13 comments:
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.
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
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.
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.
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.
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...
Hi dev.null.box,
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.
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.
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.
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).
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 (http://en.wikipedia.org/wiki/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.
"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.
Post a Comment