From: Ben Giddings <bg-rubytalk@...>
Date: 2004-05-20T02:35:32+09:00
Subject: Re: How to duck type? - the psychology of static typing in Ruby

Hal Fulton wrote:
>> 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.
> 
> A code coverage tool (combined with unit tests) can help this. There's
> one in RAA.

As good as a code coverage tool is, it still only works with running 
code.  It will tell you what areas aren't being used regularly, but then 
you have to find a way to check them.

What I'm looking for is more what another poster mentioned:

> A better example is that perl does exactly what you were asking for
> otherwise (behavior when -c and -v are both supplied to the ruby
> interpreter):
> 
> jenova ~ % cat -n what.pl
>      1  $num = 3;
>      2  $num += 2;
>      3  if ($numb != 5) {
>      4       print "Foo!!\n";
>      5  }
> jenova ~ % perl -cw what.pl
> Name "main::numb" used only once: possible typo at what.pl line 3.
> what.pl syntax OK

At no point does it try to run the code, but it still finds that 
potential trouble spot.

I think unit tests are great, so are code coverage tools, as are 
profilers and debuggers... but I still see a need for 'typo catchers'.

Ben