Ben Giddings wrote:
> Once again, static typing reared its head on the mailing list, and once 
> again, the knights of the Ruby table slayed the beast... but it will 
> return.  The wheel of time continues to turn and the beast will return 
> again.
> 
> But really, when people talk about "static typing", what is it they 
> *really* want.  What does static typing buy you?  I'd argue it's simple.
> 
> Static typing tends to find typos and brainos in code before it's executed.
> 
> It's as simple as that.  I don't need to talk about the various down sides 
> to static typing here, but that upside is particularly important when 
> there are bits of code that might very rarely be executed.
> 
> So the real question is: in a dynamic, strongly typed language like Ruby, 
> how do you find typos and brainos in code that your app may very rarely 
> use?
> 
> The stock answer here is "unit tests", but honestly, I never bought that 
> answer.  Maybe it's because too often I deal with things that are 
> incredibly difficult to unit test, i.e. GUIs, external data sources, 
> unreliable networks, opaque 3rd-party interfaces and other things which 
> are very difficult to mock out.  It isn't to say they aren't testable, 
> just that they're really hard to test well.
> 
> My open question is then: how do you find typos and brainos in seldom-run 
> code in a dynamic language like Ruby?
> 
> (And maybe we can use the answers next time the monster rears its head)

As I read this, I immediately imagined parsing all the individual tokens 
  in a set of Ruby programs, and counting the number of occurrences of 
each. Tokens that appear infrequently (like once) are likely to be typos.

This idea, with a little more smarts added, could be used to detect 
potential typos.

Curt