Re: How to duck type? - the psychology of static typing in Ruby

Robert Klemme wrote:
>>I worry more about the hazard of undeclared variable names.  There's a
>>story, probably apocryphal, about a space probe being lost back in the
>>1960's because somebody held down a keypunch key too long and turned the
>>variable X into XX on the left-hand of an assignment.  Since FORTRAN4
>>didn't require explicit declaration of variables, the calculation was
>>stuffed into XX (which appeared nowhere else in the program) and X
>>contained an incorrect value for subsequent calculations.  Because of
>>this story, I worry sometimes that variables need not be delcared in
>>Ruby.  I realize that since everything is an object there's no need for
>>type declarations.  However, I think variable set declarations would
>>make some sense - "Here's the set of variable names I'll be using, and
>>anything not in this set is a typo."
> 
> If there were proper tests in place they'd certainly catched that one.
> Declarations could only prevent the accidental usage of an undeclared
> variable.  But they can't ensure calculcations and algorithms are done
> properly.

I have a beef with this attitude.  Of course you'll catch this error if 
you have a test in place to test for it.  Of course proper testing will 
ensure a working product.  Of course testing for undeclared variables 
won't prove you have a working program.  That doesn't mean it's useless. 
  In fact, this is one of the most useful features of compilers in a 
compiled language.

Matz has often said that one of his major goals with Ruby is to make 
things easy for the programmer, unlike most languages that make things 
easy for the computer.

Checking to see if you're assigning to an undeclared variable is one of 
those really helpful things that a computer can do for you.  It can't 
easily prove the correctness of your algorithms, it can't easily decide 
if your code needs to be refactored.  But catching this kind of typo is 
something that it should be pretty good at.  So, why is this a bad thing?

Sometimes, you don't want the extra keystrokes of having to declare your 
variables.  That's fine.  But, sometimes you really want typo detection.

$num = 2
$num += 3

if ($numb != 5)
   puts "foo"
end

If I run the above by default, it just prints "foo".  If I run it with 
'-v' it tells me:

ritf.rb:7: warning: global variable `$numb' not initialized

That's some really useful information!  It's a shame that I get that 
information too late.  At this point my program is already running and 
already doing the wrong thing.

I think it would be great if there were some analysis software for ruby 
code that would look over it, and without actually running it, find 
potential problems like this one.  This would be the equivalent of 
compiling a C program, in that it would weed out all the obvious typos 
and similar mistakes.  This could even be the behaviour of 'ruby -c' if 
the '-v' flag is supplied.

Among people who don't program Ruby, one of the biggest complaints I've 
heard is that they'd be scared to create a really big program in Ruby 
because it wouldn't find a simple typo until it is actually executing 
the code at that point.  If it's a rarely-hit spot, then it could be a 
long time before it is discovered.  This concerns me too -- but I'm a 
big enough fan that I overlook this flaw and use Ruby anyhow.

One of the few things that Perl still has that Ruby doesn't is this:

use strict;

$num = 3;
$num += 2;
if ($numb != 5) {
     print "Foo!!\n";
}
% perl perl.pl
Global symbol "$num" requires explicit package name at perl.pl line 3.
Global symbol "$num" requires explicit package name at perl.pl line 4.
Global symbol "$numb" requires explicit package name at perl.pl line 5.
Execution of perl.pl aborted due to compilation errors.

It's an option.  You don't have to use it, but for critical packages, 
most people do.  Sure, it's nothing more than partial typo detection, 
but is any of us really prefekt?

And besides, if you think proper unit tests will catch all your errors, 
so you don't need this type of check -- what if the typo is in  your 
unit test?

Ben