From: "Octavian Rasnita" <[EMAIL PROTECTED]>
> Perl has a big advantage from the perspective of the initial programmer, but
> a very big disadvantage from the perspective of the maintainer, and this is
> "There are more ways to do it".
I don't see this as a disadvantage. Different ways may be better in
different places. And the several ways to write even a single
statement let me express the intent better than if I was restricted
to just a single way. Though I admit I sometimes go balistic over
someone elses code. Things like
print "<TR>\n";
print "<td class=\"bar\"><b>baaaar</b><br/>\n";
print "<a href=\"$url\">foo</a>";
... and so forth for twenty more lines
drive me up the wall. But the catch is that this is exactly what I
would have to write myself if there were not the several ways to
write a string literal.
What this does mean though is that maintenance programmers need to
learn more of the language than those that are writing scripts just
for themselves.
> I also don't like at all the Visual Basic style of expressions that are not
> ended with a ; but with an end of line, however, many programmers say that
> this is very nice, because too many punctuation chars make the program
> harder to read.
I find both
puts 1 + 2 +
3
and
puts 1 + 2 \
+ 3
much harder to read then I would
puts 1 + 2
+ 3;
(This was Ruby, it is "bright" enough to merge two lines into a
single statement if the first ends with an operator or something
similar. It's not bright enough to do so if the first line has a
brace open. So this
puts (1 + 2
+ 3)
would not work. Though at least it fails noisily.
> The programmers in ruby and python (and other languages) use to
like
> separating the expressions in more smaller parts, while the perl programmers
> like very often to use a bigger expression in a single line, and this makes
> it harder to read. For example:
>
> my $id = 123;
> my $name = get_name($id);
> my $age = $age{$name};
> print $age;
>
> is often written in perl as:
>
> print $age{get_name(123)};
It's hard to find the right border here. Split it too much and you
break the otherwise simple action in too many steps. Make the single
statement too long and people will be unable to decipher it. I guess
I'm a bit far on the "don't introduce additional variables and lump
it all together in one statement" scale.
On the other side are those that turn off their brains and start
running around screaming "Unreadable! Unreadable!" as soon as they
see a "map".
> Also, perl remains a language for Unix platforms. It is much used under
> Windows, but there are more perl modules that don't work at all under
> Windows, or that work badly, or which work with a version of perl but don't
> work with the next one...
I don't agree here. This was true back in, say, '97, but it's not
now. When I started with Perl the manpages were full of references to
Unix manpages (a lovely thing if you work under Windows with no
access to any Unix) with even things like printf() being explained as
"Works the same as printf(3)". The list of important modules that did
not work under Windows was also quite long, but now most of the
modules you'd want to use either do work or have a Windows only
counterpart or are too Unix centric to be of any use. IMHO of course.
Jenda
===== [EMAIL PROTECTED] === http://Jenda.Krynicky.cz =====
When it comes to wine, women and song, wizards are allowed
to get drunk and croon as much as they like.
-- Terry Pratchett in Sourcery
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
