Most of Perl's strengths are also it's weaknesses. Let me give some examples to help explain what I mean:
- I can write code in one of many ways (there's more than one way to do it). This is good: it can save work for me, as an author.
Unfortunately, so can everyone else. This is bad: it can create a lot of work for me as a code maintainer. I may end up having to decipher ten different idioms to maintain ten different people's code. So will each of the other ten people, if they have to read each other's code.
- On the plus side, Perl lets total newcomers churn out code quickly. On the minus side, Perl lets total newcomers churn out code quickly: and usually, in a few years, the company has to hire an expert to clean up the mess they've made. Again, the novice author may only need to understand a small subset of Perl to write code. The code maintainer, who doesn't know which features a given author may have used, needs to know all of Perl before he can be confident he can fix it. Gambling on not needing code maintenance can be costly.
- Perl has nice, English friendly syntax, for doing some things ("if" vs. "unless", for instance). Unfortunately, it has horrible syntax for others. If I want to create global variable, I use the keyword... "our"? If I want to create a local variable, I use "my". If I want to temporarily override the value of a global variable, until the current block scope ends, I use "local". Here, Perl's history has made the syntax ugly and unfriendly. By contrast, adding "unless" to the language doesn't gain all that much.
- I like that perl functions take a list as input, and return a list as output. I dislike the lack of a named paramter list: again, using an obscure @_ variable to handle the argument list is confusing. The fact that @_ modifies it's variables, and only complains if this is impossible at run time is annoying.
I want proper named parameter lists, with variables explicitly marked as modifying their callers if that's what they are to do. Whenever I try to explain Perl functions to people, they usually pause in confusion right when the hit the @_ line -- I end up having to say it's there because "it's Perl and yes, it's ugly, but it works".
- Exception handling: it's ugly in Perl. There's no standard set of exceptions thrown by CPAN modules (too often, "there's more one way to do it" means "well, no one's agreed on a standard yet"). If I inherit a chunk of code, it's not clear what exceptions are thrown, nor what's done with them. Calling "die" to raise an exception is somewhat obscure. Expecting someone to have read the section on 'signal handling' when they want to catch a signal raised by "die" is worse.
- Perl's data structures are dynamic and flexible. This means that if I want to, I can create free form data structures that conform to any pattern I like.
On the down side, I can do this by accident, even if I don't intend to. If I accidentally refer to something that doesn't exist, Perl creates it for me. If I intend for all elements in my list to have the same structure, Perl doesn't enforce that for me.
- Perl has packages, which were a good idea. On the down side, $::x was chosen to mean global variable x in the main package, not the current package. As a result, I have to choose between using the "our" keyword, and not having global variables stand out as special, or fully qualifying them with a package name, and then using a global search/replace to change them all. I can violate package encapsulation: by design(good), by accident(bad),or by misunderstanding (typical).
- Perl has objects, and presents the notions in a simple enough way that it's clear even to someone with a non-OO background what they do. On the other hand, it lacks a lot of typical OO features: unless you work hard at making your objects tamper proof, they're not.
- Tied objects mean I can't trust code to do what it says it does. If I include a suspicious module, I can't be sure that "$x = $x +1" does what I want it to. It also means an optimizer can't assume $x=$x+1 will increment the scalar variable $x.
- Perl's syntax is complex and variable, to allow poetry to be written, and to attempt to "do what I mean" in several cases. This makes it hard to figure out when Perl is doing something which is not "what I mean". It also means that code which tries to process Perl programs, such as Perl specific IDE, will have a hard job. I know, because I've thought about how to do it, and it's not easy.
I'd love to see a refactoring friendly IDE that let me rename all variables within a given scope, or one that automatically updated all function calls when a function name changed within a given project. What about a search function that only applied within a given scope, so I could search for all variables used within the ugly 3,000 line loop I'm trying to refactor into something sane? It would be nice, but just parsing out where a function starts and ends is hard work. ( Look at how complicated the B:: family of modules still are, and remember that people have worked on them for years. They're still all marked experimental.)
- Documentation: I have a love/hate relationship with Perl's documentation. Perl has it, which is good. It's almost always correct, which is better. On the other hand, a lot of it is glib, riddled with jargon, and/or missing important sections. For example, the section on regular expressions assumes prior knowledge of regular expressions.
The section on watchpoints in the perl debugger arrogantly assumes knowledge of watchpoints. It doesn't explain how to set at watchpoint that's only triggered when a specific value is reached, which I could do back in 1991, using C. under MS-DOS. This is not progress. (And no, I still don't know how to do it in Perl. If anyone does, please tell me!)
The section on the $_ variable in perlvar still reads: "various functions" when it tries to explain the places where $_ may be used, rather than spelling out the list of functions. (Whose arm do I need to break to get this fixed, BTW? It's been like that since 1995, and everyone I talk to hates it. Some of my friends stopped trying to learn Perl, mostly because of confusion of $_, and the related sense that Perl was obscure and incomprehensible.)
- Perl should default to assuming local variables within functions, when use strict is not applied. This would make turning programs into the stricter variant much, much easier.
In summary, I clearly like Perl, or I wouldn't have stayed with it for ten years. On the other hand, I think it has a lot of shortcomings as well, some of them fixable, some of them inherent to it's strengths. It's not always the right tool for the job, but it often is: I see it not as a Swiss Army Chainsaw, but as a tricky little jigsaw, complete with a big set of stencils and templates (CPAN). It's capable of cutting out puzzles and other oddments, but slower than the giant buzz-saw that is Assembly Language, or the bandsaw that is C. It does a different job than the lathe in the corner (LISP and the functional programming family), and takes a different approach than the big factory assembly line of blades and conveyors used by Java and it's cousins.
Perl is small, simple, and effective: if a little obscure.
It's also fun to use. Okay, this post is
definately long enough.
--
Ytrew