Don't worry, this post is not an Apocalypse, however,
it may refer to certain passages from St. Larry Wall's writings therein.
As Larry Wall himself puts it:
"Multiple syntaxes sound like an evil thing, but they're really necessary for the evolution of the language. To some extent we already have a multi-syntax model in Perl 5"
Perl is particularly insensitive to individual programmer's coding styles and syntax, so long of course it 'compiles'. I believe this allows Perl to be regarded as a tool for expressing one's creativity and culture while still doing his/her job. This is unarguably a good thing. However, to some extent this rather liberal feature of perl is subject to common abuse if not approached with due diligence.
As Larry Wall himself puts it:
"Multiple syntaxes sound like an evil thing, but they're really necessary for the evolution of the language. To some extent we already have a multi-syntax model in Perl 5"
Perl is particularly insensitive to individual programmer's coding styles and syntax, so long of course it 'compiles'. I believe this allows Perl to be regarded as a tool for expressing one's creativity and culture while still doing his/her job. This is unarguably a good thing. However, to some extent this rather liberal feature of perl is subject to common abuse if not approached with due diligence.
Poorly composed and formatted perl code most often serves as the prevailing deterrent for newcomers to this language. And this is certainly a bad thing, especially for Perl
advocacy groups and individual perl evangelists alike. For one I know, my heart rejoices
when I see an old friend of mine well versed in the manners of other languages (such as C/C++,
for example) convert to and partake in the joy of breathing, writing, and thinking Perl.
A few days ago, I stumbled on an old article (dated back to 2001) which sheds a little more light on this very subject. The post is titled Perl: ugly and not suitable. Here's a startling quote from a follow up reply post:
"Perl's main drawback is that parts of it are irredeemably ugly, complicated, and must be used with caution and in stereotyped ways lest they bite (its argument-passing conventions for functions are a good example of all three)"
Being as much of a Perl devotee as I am, my first reaction would be to sharply disagree with this conjecture. On the other hand, however, there's always a grain of truth in every lie ;-). There are horrible ways of dealing with subroutine arguments as well as there are elegant ways. Most of it is described to some extent in these posts: To summarize, I tend to believe most of us would agree that dealing with subroutines (especially in a piece of code you inherited from another developer) that accept over four arguments is not the best experience one would prefer to go through. Here's an example:
Do you have your stories of good, bad, or outright ugly Perl code? While trying to keep this post short, I would appreciate a continued discussion. Thanks for your attention ;-).
A few days ago, I stumbled on an old article (dated back to 2001) which sheds a little more light on this very subject. The post is titled Perl: ugly and not suitable. Here's a startling quote from a follow up reply post:
"Perl's main drawback is that parts of it are irredeemably ugly, complicated, and must be used with caution and in stereotyped ways lest they bite (its argument-passing conventions for functions are a good example of all three)"
Being as much of a Perl devotee as I am, my first reaction would be to sharply disagree with this conjecture. On the other hand, however, there's always a grain of truth in every lie ;-). There are horrible ways of dealing with subroutine arguments as well as there are elegant ways. Most of it is described to some extent in these posts: To summarize, I tend to believe most of us would agree that dealing with subroutines (especially in a piece of code you inherited from another developer) that accept over four arguments is not the best experience one would prefer to go through. Here's an example:
However, passing a hash structure where subroutine parameters are clearly expressed through hash key names is aesthetically clean and provides for a flexible way to manage subroutine arguments (adding new parameters or removing old ones). I regard this as a truly seamless way of dealing with subroutine arguments that is unmatched in any other programming languages such as C++, Java, Basic etc.sub create_index { my ($dbh, $index_name, $frontend, $backend, $scoring) = @_; . . . } . . . my $index = create_index($dbh, 'search_index', 'string', 'phrase', 1);
Of course, there are some extreme rebels who would be opposed to the whole idea of using some 'ubiquitous' @_ variable to handle subroutine parameters. Well, and I'm not in here to argue with them - evidently, nothing could bring such a vial heart to repentance ;).sub create_index { my %args = @_; # retrieve/use subroutine parameters from the # %args hash! . . . } . . . my $index = create_index( dbh => $dbh, index_name => 'search_index', frontend => 'string', backend => 'phrase' scoring => 1 );
Do you have your stories of good, bad, or outright ugly Perl code? While trying to keep this post short, I would appreciate a continued discussion. Thanks for your attention ;-).
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith |
|
---|
Back to
Meditations