From: SER <ggg@...1.net>
Date: 2005-04-30T06:04:30+09:00
Subject: Re: ruby static typing

> I question whether a tool can analyze the capabilities of an object
> whose capabilities are subject to runtime-only changes.  To the
extent

This is a good question.  I've often expressed my approval of strong
typing, although I'm a proponent of type inferrence, rather than the
more common proposals for adding typing syntax.  However, as I've often
said, a system like this would be useful to generate warnings, not
errors.  If there was a typing system in Ruby, I'd have it use type
inferrence, and it would be enabled only when the user ran "ruby -c" on
their sources.  It would generate warnings like:

  WARNING: foo.rb:15:          diddle.parse
        'diddle' originally defined in babble.rb:24 as an Array
        foo.rb::boozle( diddle ) called from fang.rb:64

A clever implementation would print the sequence of method calls that
led to the type error:

  TYPING WARNING: foo.rb:15:          diddle.parse
        'diddle' originated in babble.rb:24 as Array
          babble.rb:24 -> geezer.rb::thang()
          geezer.rb:18 -> homer.rb::fink()
          home.rb:23 -> lala.rb::trixie()
          lala.rb:84 -> foo.rb::boozle()

Aside from typos, this is the most common sort of error in *all* of my
Ruby applications.  Through a series of method calls, an object that I
think answers to some method isn't the object that I think it is.  I've
had code that passes all of the unit tests I can think to write, and
gets used for a week *before* an error of this type up.  These are the
most common sleeper errors I encounter.

Again, in some Ruby programs where the objects have methods dynamically
added, you'd get false warnings.  They're warnings; you look at them,
find out that they're false positives, and ignore them.  If it really
annoys you, don't run the checker.  It isn't unreasonable to assume
that, once you have the basic type inferrence system in place,
extending it to recognize simple cases of dynamic class/object
extension wouldn't be too difficult, and the number of false positives
would be reduced.  But the main point is that we'd have an additional
tool for checking the code *before* deployment, rather than discovering
it when it is in production.

I think that people who are most afraid of strong typing are people who
were bitten by Ada, or C, or Java, or some other language where you
spend a lot of time declaring variables.  They are, by and large,
people who've not had any experience with languages that have type
inferrence, like Haskell.

My standard caveat applies: type inferrence can be a tricky problem,
and requires tight coupling with the parse tree of the sourcecode.  I
don't complain about not having it because I'm not willing to write it
myself, but I'm happy to voice my opinion when other people bring up
the topic :-)

--- SER