Ted Ashton wrote:
>
> > 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.
>
> Nope. I've yet to be convinced that "fits in your head" is the same as
> "went in easily". Hang it all, English is hard to get at first--just ask my
> seven-month-old (and my 4-year-old). But once in there, it's so blooming
> useful.
True, and an important thing to keep in mind. But there are many
different levels of mastery of English. Going up those levels enables
one to express things more easily and/or precisely. I don't want Perl to
be as difficult to learn as English or any other natural language. A
person has a certain budget of time and effort to expend for a given
payoff, and Perl just isn't going to command the resources devoted to
one's native language. So the learning curve, from beginning to end, is
critically important in language design -- people will distribute
themselves along the learning curve, and you'd like to give them as much
benefit as possible for their trouble. It's as precise a measure of
"success" as I can come up with.
Which has next to nothing to do with any particular issue. And it's too
hard to argue when we agree.
> It seems to me that we're arguing about multiple things here. We seem to all,
> grudgingly at least, agree that $a, @a and %a when they are simple straight
> forward things are useful. It appears that the big problems come in two
> places. First, there's some confusion about the $,@,%. Programmers coming
> from elsewhere think that they are part of the variable name and just specify
> what type of variable it is, as in other languages. They need to be taught
> rather that those things are context. That's a learning-curve issue and, I
> contend, worth the learning.
If I asked you which variable $x[4] is accessing, I bet you'd say @x.
Which is one source of the confusion -- in one case, you use $@% to name
the variable, and in the other, to provide context. Which leads to the
other source -- $x[4] leaves unstated which variable is being
manipulated; you have to infer it from the manipulation. And that's a
set of rules that must be memorized. Which isn't that hard, but it's why
I'd like to put a ladder up that little cliff on the learning curve by
asking the compiler to tell you what you're screwing up instead of a
seemingly unrelated message.
> The other big problem is that crazy @{} and $a->[] stuff and while I don't have
> any particular solution, I agree that that is confusing and ugly. Even once I
> got my brain around what it all means, it still looks downright ugly as far as
> I'm concerned. Anyone have solutions to that?
My proposal would be what I implemented for perl5 a while back (Sarathy
didn't dislike it, but wasn't convinced enough to put it in): all
dereferencing can be done with ->.
$x->@ is the same as @$x
$x->% is the same as %$x
$x->@[1,2,3] is the same as @$x[1,2,3]
$x->@{a,b,c} is the same as @$x{a,b,c}
f()->@ is the same as @{ f() }
more problematically,
$x->$ is the same as $$x
($object->$methodname causes trouble, eg $x->$s/.... Is that division or
regex substitution?)
But it's not a big step forward.
