Re: Larry Wall's comments on Ruby

* Phil Tomson ([e-mail]) wrote:
> http://interviews.slashdot.org/article.pl?sid=02/09/06/1343222&mode=thread&tid=145
> 
> We may not agree with what Larry has to say about Ruby, but as usual he 
> says it well.
> 
> The relevant part:
> 
> "As for specifics, I must say that the example of Ruby is the main reason 
> I decided against implicit lexical scoping for Perl 6. We'll be sticking 
> with explicit my declarations. But I have to like the majority of Ruby 
> simply because that's the part that was borrowed straight out of Perl. :-) 

I'm suspicious of anything Larry, or any of the top Perl brass, have to
say regarding scoping rules.  Variable declaration in Perl is a
nightmare: do you use "my", "our", "local", or a filehandle?  Be
careful! The scoping and namespace rules change in subtle and nefarious
ways depending on the declaration.  It's even worse if you plan on using
references (or, more accurately, one of the three different types of
references), since the scoping and namespace rules change in subtle and
nefarious ways depending on the declaration.

Examples of this madness?  A "local" variable isn't really local; it's
valid in nested subroutines as well.  A top-level "my" variable isn't
really global to the package; you have to use "our" in order to allow
that behavior (this distinction is important if you're using symbolic
references instead of scalar references).

Perl doesn't have the best track record regarding sane scoping rules.
Oh, I'm sure they have it all figured out _this_ time around, and they
promise to get it right in Perl 6.  As Linus says, show me the code.  If
I sound bitter, it's because I've been burned by this mess more than
once. That said, Ruby does have its scoping quirks (eg eval and closure
block ambiguity), most of which have been beaten to death on this list,
so I won't bother regurgitating them here.

> I also liked Ruby's unary splat operator, so I borrowed it for Perl 6. 
> 
> The main problem I see with Ruby is that the Principle of Least Surprise 
> can lead you astray, as it did with implicit lexical scoping. The question 
> is, whose surprise are you pessimizing? Experts are surprised by different 
> things than beginners. People who are trying to grow small programs into 
> large programs are surprised by different things than people who design 
> their programs large to begin with. 
> 
> For instance, I think it's a violation of the Beginner's Principle of 
> Least Surprise to make everything an object. To a beginner, a number is 
> just a number. A string is a string. They may well be objects as far as 

That's simply not true.  If a number is an number, then it shares a set
of common characteristics with all other numbers.  Is it zero?  Is it an
integer?  What integer does it round to?  Even non-technically inclined
people think this way; sets of things are grouped together because they
share attributes.  As Andy says in another response, there's nothing
counterintuitive or complicated about making this natural thought
process a fundamental aspect of a language.  On the contrary, the
unnatural distinction between objects (thingies which possess attributes)
and primitives (thingies which are magically exempt or devoid of
attributes) is counterintuitive and confusing for beginners.  Larry
should know better.

> the computer is concerned, and it's even fine for experts to treat them as 
> objects. But premature OO is a speed bump in the novice's onramp. "
> 
> Personally, I like Ruby's scoping rules a lot better than Perl's.

Obviously I agree. :)

> Also, I think that everyting being an object is actually helpful for 
> beginners - It's much easier to pick up OO programming ideas if you learn 
> them first, I think.  It also tends to make things much more consistent.

Again, I agree.

> Thoughts?
> 
> Phil

-- 
Paul Duncan <[e-mail]>        pabs in #gah (OPN IRC)
http://www.pablotron.org/               OpenPGP Key ID: 0x82C29562