Re: [wxperl-users] declarative syntax (please, "longer" ne "better"!)

[Eric W. <scr...@gm...>]

# from Sergei Steshenko
# on Sunday 18 March 2007 04:08 pm:

>> =A0 ...
>> =A0 funky_array =3D> do {my @p =3D (1,2);
>> =A0 =A0 [1,2,map({push(@p, my $v =3D shift(@p)+$p[0]); $v} 3..100)]},
>> =A0 ...
>
>Why should I load my brain trying to understand what $p means ?
>And what is $v if I may ?

Well, one-letter variables that only appear within a closed block on two=20
lines of code never bothered me.  I prefer to think about the algorithm=20
and not whether the code *appears* to be readable.  It's encapsulated=20
by virtue of its seeming opacity.

>I prefer readable code, not a short one.

I prefer correct code.  If my subtlety eludes you, go run yours and see=20
what answer you get.  It is just a long-winded [map({2**$_} 0..99)]=20
(i.e. a doubling sequence) which is at-a-glance very readably wrong.

I really don't understand why so many people seem to think that longer=20
code is somehow better and more readable.  Have they had a readability=20
study?  Would you call a 5000-page novel "readable"?  Is a 20-hour=20
movie "watchable"?  If you're writing 10 times as much Perl as you=20
should, why not just use C?  You'll have the same number of bugs, but=20
they'll run faster :-D

A local news station once had (maybe still does have) the slogan "Clear,=20
accurate, and to-the-point."  I always thought it ironic that they=20
would use so many words to claim that they are "concise".

I'm not claiming that code should be all one-character variable names in=20
a single chain of compile-time map() statements with no carriage=20
returns (for that, you need lisp.)  Rather, code should not be any=20
longer than it needs to be.  A large part of Perl's expressiveness=20
comes from context, implied information, and concision.  There's more=20
than one way to do it, but there's a whole lot of ways to do it wrong.

Concise and correct code beats long-winded incorrect code.  Further,=20
short and incorrect code is easier to fix.  In fact, the longer code is=20
obfuscated by its shear size.  Ever heard the phrase "needle in a=20
haystack"?  For code to be readable, you have to understand what it is=20
doing.  I could use utf8 with greek characters for variable names and=20
it would make as much sense and still be correct.  We have two things=20
@p which get rotated as the new one $v arrives.  How is that more=20
complicated than your longhand variable names?  (If you haven't found=20
the bug, I think you need yet another variable to hold the new value. =20
Then it will give 1,1,1,1,1 instead of 1,2,4,8,16.  But to get=20
1,2,3,5,8,13 you have to deal with the seeding.)

So you want better variable names and comments?  Fine.  The algorithm is=20
still more clearly (and correctly) expressed in less code.

  funky_array =3D> do {
    my @pair =3D (1,2); # previous pair
    [1,2, # seed first
      map({ # roll-over the pair while calculating the next val
        push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      $new_value
    } 3..100)]
  },

Or,

  funky_array =3D> do {
	my @out =3D my @pair =3D (1,2); # seed/previous pair
	for(3..100) {
      # roll-over the pair while calculating the next value
      # I call it '$new_value' because it is new, and a value.
	  push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      push(@out, $new_value);
    }
	\@out
  },

Well, that's getting long-winded.  But, to make sure the dead horse is=20
thoroughly beaten, let me just say that you (hopefully) won't be=20
searching your codebase for bugs and skimming this e-mail in=20
=46oo::Bar.pm.  Code is going to be read/skimmed over and over and over=20
and over and over again.  You pay for the extra lines of code *all the=20
time*.  You only pay for the extra density when you're working on that=20
particular chunk.

=2D-Eric
=2D-=20
"Because understanding simplicity is complicated."
=2D-Eric Raymond
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------