On May 17, 2004, at 22:52, James Britt wrote:
> One (possible, and not mine) argument against duck typing is that you 
> are essentially required to write assorted unit tests beyond checking 
> for operationally correct behavior; the compilation step for a 
> staticly typed language offers these (albeit compulsory) "unit tests" 
> for free.

No one requires you to do this. Instead, you do this if you feel 
uncomfortable with your code. After a while, you stop feeling 
uncomfortable, and realize that all this type discussion is simply a 
red herring, and get back to writing proper code and the tests to test 
it. A few months after that, you're surprised when you realize that you 
haven't had a single type-related error.

This is simple a question of experience. When you first start out, you 
feel exposed because Ruby doesn't let you add type annotations to 
variables (I know I did). Knowing that it worked OK in Smalltalk, I 
made the conscious decision not to fight this, but instead to see how 
it worked just doing it the Ruby way. It was hard at first, and I kept 
fighting some inner demon who wanted me to add "kind_of?" calls 
everywhere. But after a while, I realized that my code was no less 
accurate than it was in Java, and that I didn't really need the type 
information. Once I overcame that fear, I suddenly realized that I 
could also get a lot of benefit from the flexibility: the realization 
that type != class, but rather that type equals capabilities was a 
revelation, and it has fundamentally changed the way I code.

However, I honestly believe that there is no short cut on this path: 
the only way to come to understand the true nature of typing in Ruby is 
to write a bunch of code the Ruby way, and to gain your own experience 
(and form your own opinions). Unit tests are a safety net that can be 
used while crossing that wire. Once across, you'll be able to form your 
own opinions about the effectiveness of unit tests for type-related 
checking.


Cheers

Dave