Hm...do I want to continue this argument? Oh, what the heck - I'm bored.
A couple folks over on James Robertson's comments can be found here and here. He mostly seems to focus on sigils.
It seems a strange argument to use the number of sigils as the basis for the "ease" of a language. Your average Perl newb will probably only see about 3 - @, %, $, plus 2 special variables, @_ and $_.
What I guess James doesn't know, or doesn't realize, is that in the case of @, % and $, they are actually meant to *help* readability. If a newb sees @, he knows it's an array. If he sees %, he knows it's a hash, etc.
Unfortunately, I never completed my PhD thesis on "Computer Programming and the Effect of Sigils on the Human Psyche", so I can't say with total certainty that this helps Perl newbs along or not, but I suspect it does. I think it's only when you get into advanced Perl, and advanced data structures in Perl, that the syntax (and sigils) start to get overbearing.
Once I became more versed with Perl, the sigils started to get in the way, and that's one of the reasons why I do more Ruby these days than Perl. I started to realize that I was only using scalars the vast majority of the time anyway, and that scalar could be anything - a simple scalar or a quadruply nested hash reference. The sigils no longer helped, and I found myself using a GUI debugger just to understand the structure's layout. But, that's another story...
Because a newbie sees the sigil and thinks: scalar$hash{element}
And he thinks: same scalar$hash
and$hash->{element}
So, as someone with a computer science degree... I wholeheartedly agree with what you are saying.$object->method
Re:To an extent...
brian_d_foy on 2004-09-15T23:27:45
But the sigil is right: $hash{element} and $hash are both scalars. I don't have a huge issue teaching this because most people get it once they know the rule: $ is one thing, @ can be many things, and % is a hash. I emphasize those points, and it works.
Most people we teach don't get $hash and $hash{element} confused either. One doesn't have a curly brace after it. This is another thing we emphasize, and we find it very easy to teach.
I can see the problem for people who teach themselves Perl from the wrong sources, though, but I've taught a lot of non-computer-science people Perl, and this hasn't been one of the things they get confused about.Re:To an extent...
phillup on 2004-09-16T00:43:15
Most people we teach don't get $hash and $hash{element} confused either. One doesn't have a curly brace after it. This is another thing we emphasize, and we find it very easy to teach.
Yep. Makes perfect sense to me. I agree totally.
But... I've got some customers that, after a week, still couldn't tell the difference between those two variables. They (mostly) get the scalar / hash thing... and getting an element of a hash.
But as soon as you give them (the scalar and the hash) both the same name, they freak when they need to get one of the hash elements.
I think that the problem is that I'm trying to teach people that have absolutely zero experience programming any language. And they don't do programming as a routine part of their job, or as a hobby. (Can you say "public school teacher"?) Great people. Not technically inclined.Re:To an extent...
brian_d_foy on 2004-09-16T00:50:28
Well, we explicitly tell them that you can have different variable types with the same name. When we introduced arrays and hashes, we hammer this into their heads.
You already know they are going to have trouble with that stuff, so you head it off before they have a chance to get confused.:)
Something I do habitually is to UpperCase objects and compound the name of a variable with what its used for e.g. copy_of_Foo or Foo_remote
Never had a problem, so much so in fact that I find myself needing comments less and less (except when looking at perl golf or scary math).