[geeks] perlish disgruntlement, java considered, sun hardware sought

[alex j avriette]

On Sunday, April 7, 2002, at 08:39 PM, Bill Bradford wrote:

> On Sun, Apr 07, 2002 at 08:28:49PM -0400, alex j avriette wrote:
>> No, Bill. I hate to call you on this, but youre flat wrong.
>
> Wrong, in that people that use the "shortcuts" make it harder to
> learn Perl by reading other people's code?  What kind of crack are you
> smoking?

We're not talking about short cuts here. We're talking about clear and 
concise code. If you cant understand map and would prefer foreach, well, 
thats fine. But my code is going to gain that 10% efficiency for its 
5,000,000 iterations.

Reducing code is fine with proper indentation. A professional perl 
programmer can easily understand concise code:

my %hash = map { chomp; /^([^@]+)@([^\s]+)$/ ? ($1 => $2) : () } 
read_file("filename")

# vs

my %hash;
open FH, "<filename";
ITER: foreach $line (<FH>) {
   chomp $line;
   if (my ($key, $val) = $line =~ /^([^@]+)@([^\s]+)$/ ) {
     $hash{$key} = $val;
   }
   else {
     next ITER;
   }
}

one can easily see how an 800 line project can rapidly approach ten 
thousand lines when the programmer is inexperienced. one can also easily 
see how people (such as yourself) think perl is unreadable. this is not 
the case. take the adage of the "perl wise":

perl is an easy language to learn. it is a difficult language to master.

because you cannot understand the one line alternative above does not 
mean that perl is unreadable or that the programmer took unnecessary 
liberties with "obfuscated code" -- it is nothing of the sort. a simple 
use of implicit variables ($_, $1, $2), an array transformation function 
(map) and an unused but valuable operator (ternary) makes code more 
efficient, concise, and, imo, readable.

>> There are better ways to do things, but somehow, in perl, its 
>> acceptable
>> to suck ass because its not "real programming", its "scripting."
>
> If you need a program, write one that works and does the job you need,
> who cares how many lines it is?  I can see this being a problem in a

right now im migrating a > 20,000 line perl program from one e3000 to a 
cluster of two e3500's with a new nfs cluster (also two e3500's). the 
code is hideous. a bug we recently encountered:

$output = `rsh username hostname command args`;
($onevar, $twovar) = split(' ',$output);

i'm sure you find that very readable. i find it hideous and abhorrent. 
your c professor would fail you for making system calls in code.

> production environment where code might get passed from person to 
> person,
> but Perl is okay for "quick and dirty" jobs.

if youre not writing code that is *fit* to be passed from person to 
person, you shouldnt be writing code. this is one of the main ideas 
behind java. see rest of previous rant.

alex
--
alex j avriette, perl hacker
avriettea at speakeasy.net
http://envy.posixnap.net/