, however,
it may refer to certain passages from St. Larry Wall's writings therein.
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:
sub create_index {
my ($dbh, $index_name, $frontend, $backend, $scoring) = @_;
. . .
}
. . .
my $index = create_index($dbh, 'search_index', 'string', 'phrase', 1);
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 %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
);
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 ;).
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
|