On Wed, 16 Aug 2000, David Corbin wrote:

> Mike Pastore wrote:
>
> >     $hashish{'dog'}        # one whutzit
> >     @hashish{'dog', 'cat'} # more than one whutzits
> >     each %hashish          # one whutzit, indexed
> >     %hashish               # all whutzits, indexed
> >     keys %hashish          # all indices
> >     values %hashish        # all whutzits
>
> > I know I'm being terribly redundant, but the point I'm trying to make is
> > that the contextual clues (@$%) don't tell you what IT is, but what you're
> > getting from IT. That's what's so important.
> 
> Fine.  But the problem (confusion) comes from the fact that you've got
> multiple "IT"s named 'hishhash' that have no real correlation.  If the
> %@$ indicates what you're getting, you've got soemthing else ([0]/{x}/)
> which indicates what IT really is.  However, that's not how you declared
> IT.  You declared (first used) @$%.

I re-CC'd perl6-language because these are some of my arguments in
general.

The correlation between the different C<hashish>es is the name. The
confusion you're describing above can be much more easily rectified by a
highlander-type solution, or simply by using Good Programming. 

Remember, it isn't the goal of Perl to be easy to learn. A Perl newbie can
spend an hour learning the difference between a scalar, an array, an array
element, an array slice, a hash, a hash slice, and the different hash
calls. This will have been an hour well spent. Then they can enter the
world of the Perl programmer, where the variable context needs to be
easily identified. Please read Dan Sugalski's recent post about how the
human brain works, I won't get into it again.

> If I did this:
> 
>       my var{};
>       my var[];
>       my var;
> 
> And then used:
>       $var, $var[0], $var{x}, @var, etc. 
> 
> It would be far more consistent.

The only difference between the above and this:

    my %var;
    my @var;
    my $var;

    print $var;
    $foo = $var[0];
    $bar = $var{x};
    @zot = @var;

Is about fifteen minutes of cognitive thinking for a new Perl
programmer, either way. He (or she) is still going to have to learn the
difference between an array (@/[]) and a hash (%/{}). 

Now, enter the mind of the veteran Perl 5 programmer (please note that I
am not claiming that I am one, but I am going attempt to think like one
for a minute :)

Scenario 1:

    my var[];

"Umm, slice? Anonymous reference? Matrix? Have I stumbled into a C
library?"

    my @var;

"A list. Next line."

Scenario 2:

    ret = grep(/hand/, var);

*puzzled expression* "Grepping a scalar for a string? Grepping a list for
a string? Returning a list or a scalar?"

    @ret = grep(/hand/, @var);

"Retrieving a list of matching array elements. Next line."

Scenario 3:

    bar = unshift(hats, foo);

"Okay, C<hats> is obviously a list, but is it shifting in a scalar or a
list of things? And is it assigning to another list or a scalar to get
the new list lenghth?"

    $bar = unshift(@hats, $foo);

"Prepending C<$foo> to C<@hats> and returning the length of the new
list. Next line."

Scenario 4:

    ret = sort { foo{a} cmp foo{b} } map zot, reverse bar;

"It looks so clean! But what does it do?"

    @ret = sort { $foo{$a} cmp $foo{$b} } map &zot, reverse @bar;

"What a mess! But I know exactly what's happening. Sorting the reversed,
C<zot()>ted contents of the array C<@bar> by the index C<%foo> and
returning a new list."

You can't argue that you can make it clear by dressing up the statement:

    ret[] = sort { foo{a} cmp foo{b} } (map zot(), reverse bar[]);

Because that would defeat the purpose of the RFC in the first
place: Decrease line noise. IMHO that's HARDER to read because my brain is
already trained to look for data containers as (@$%) and not
trailing ({}/[]/()).

__END__

I get angry when anti-Perlites critiscize the language because it's
"messy." It may be, but I can tell what it does in a flash because of
context clues. Give me braces, parens, and identifiers, or give me death.

Drop off the mnemonics and sure, the simple stuff gets simpler-looking. But 
you have to read more to get the same birds-eye view. And the complicated
stuff looks streamlined, but you have to analyze two pages of code for
three minutes to determine what's a scalar, what's an array, and what's a
hash. 

If you folks want a language that's flexible, powerful, fun to code, and
easy to understand with a little brain juice, then you have Perl. If you
want a "clean" language then you're in the wrong place.

<stepping down from soapbox>

--
Mike Pastore
[EMAIL PROTECTED]


Reply via email to