Ted Ashton wrote:
>
> Thus it was written in the epistle of Russ Allbery,
> >
> > This falls firmly in the category of things that are powerful for
> > experienced users of the language but may be somewhat difficult to learn.
> > I don't think Perl has being easy to learn as it's primary goal, nor
> > should it.
>
> Russ,
> Would mind saying that again? It's been said much too seldom around here
> and it's really refreshing to heard it put into works.
>
> Being easy to learn is not Perl's main goal.
>
> That goes in with
>
> Being a perfect CS language is not Perl's main goal.
>
> I don't know for sure what Perl's main goal is, but it's definitely significant
> to Perl to make life easier and it has done that. The prefixes and context
> sensitivity make Perl easier to read and to write and the fact that it makes
> better use of the entire printable set is an asset and not otherwise :-).
Bah. I will claim neither that being easy to learn is Perl's main goal,
nor that I know what Perl's main goal is, but I have enough of an
intuition (or did I misspell "opinion"?) to assert that ease of learning
is a far more important _benchmark_ than, say, orthogonality or
buzzword-compliance or computer sciency coolness.
My standpoint is that Perl strives to be something that fits naturally
in your head and allows you to write code that pertains directly to your
problem, as opposed to spending a lot of time building abstractions and
twiddling bits and types and worrying about the "cleanliness" of your
code. "Fitting naturally into your head" means borrowing from natural
languages, creating shortcuts for common problems, and using a healthy
dose of DWIMmery. But the most direct way to measure how well the
language slides into people's heads is by seeing how hard it is for them
to get the hang of it. People shouldn't have to "Think Different" to get
their jobs done, they should be able to write their existing thoughts
down as code. Yes, they'll need to learn the language first, but it
shouldn't require too much real estate in their heads. I think we should
be arguing over "conceptual bloat" at least as strenuously as code
bloat.
Whew. That went a long way away from whether to allow %x and $x in the
same program. And I don't even want to argue that too strongly, because
use strict 'vars' provides a pretty good electroshock teaching method
for my $x = { a => 10, b => 20 }; print $x{b}. I just wouldn't mind
being able to tell the compiler that I mean $x when I say x independent
of the dollar signs and {'s surrounding it, and in turn it could tell me
"hey, you're trying to use $x as a hash, stupid!" instead of "I haven't
heard of that %x you're talking about". Or worse, the actual message
"Global symbol "%x" requires explicit package". What %x? I didn't say
%x. And how do I give it an explicit package?
It's true that I personally don't make that mistake any more. But I did,
for a long time, and so did (or does) every other perl programmer I
know.
And I still can't keep $$x{phbbtt} straight in my head.
