From my perspective as a recent convert to Perl, but with a history of several (at least 10 not counting dialecs), the main reason I found Perl harder to get to grips with is somewhat similar to the reasons I find flying a plane harder than driving a car or riding a bike.
Basically, at any given moment there is more going on in Perl/a plane than in say C/the bike or Java/a car or C++/a darn great truck.
In C, even with the comma operator and side effects, each single line is doing something fairly simple. A single line (by some definition of line) in Perl can be doing a great deal, and often more than one thing. As with the terrestial vehicles moving in two dimensions on a single plane with relatively few and simple controls, the plane can move in 3 dimensions and has many and complex controls.
So it is with Perl. With all its special vars, context sensitive functionality, myriad and sometimes magical operators, DWIM features, each line can and often is doing many things at the same time. This can make it difficult for the neophyte to seperate out each individual step, and this can lead (as it did me at the beginning), to quite intense frustration when you simply cannot see how or where things are changing, usually in a way that isn't desirable.
However, like the plane, Perl usually will reach its destination first.
However, these problems have to be balanced with the fact that because each line is capable of doing much more than most other languages, there are usually fewer lines for any given algorithm. This, once the eye aquires it's perlish sunglasses (as the quip would have it), means that as a viewer or author of the code, you can usually see more of the program in a single screenful. This, to me at least, is a great boon. Whereas in Java and C++ I was always seeking larger and larger screens and resorting to smaller and smaller fonts in order that I could view enough code in a single view that my eyes could take in the flow of the code without needing to scroll. As a perl programmer, I have rarely found the need to introduce subroutines into an algorithm purely for the sake of breaking a long, monolithic chunk of code in smaller, visually accessable bits.
I have resorted to creating called-once subroutines in both C++ and Java often. This is partly because of the natural verbosity of these languages, but more usually because it is required by the strictures of the languages.
I (again personally) strongly favour writing 3 lines of comments to illuminate one line of efficent, idiomatic code in preference to breaking that line up into 3 lines with temporary variables in order to avoid the comments. I realise that is a very personal view.
I also think that one of the biggest problems encountered with maintainance is that there are way to many programmers around who are quite happy to learn only the basics of any given language rather than explore its full potential. It reminds me somewhat of reading the tabloid press. Short, easily digestable sentances constructed with the lowest common denominator of audience in mind. Spend half an hour reading this kind of prose and then switch to something that does not aim itself at that audience and instead uses the full power and beauty of the english language and you get a feel for the problem.
As we (used to) say over here, just my two peneth on the subject. I should also warn that I am still evolving my personal Perl style, so you may be well advised to take what I say with a pinch of salt. I may yet change my mind as I start coding larger and more complex systems in Perl.
In reply to Re: What is maintainable perl code?
by BrowserUk
in thread What is maintainable perl code?
by disciple
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |