One of the pains of the statically typed method signature is that various different requirements tend to get bundled up together. A method may well require a parameter to be of type (implement interface) X, where interface X defines 10 methods, even though the method will only call one of those declared methods. Ideally you would define a new interface for each combination of methods you want to call so you can keep the contract as simple to fulfill as possible, but this in itself would be a burden as the amount of interfaces would explode.

I agree with you.
I expanded a bit about this some time ago . It’s interesting to note that the number of interfaces needed to respond to all posible clients of a class with n methods would be 2^n - 1. It really explodes!

Agreed that Ruby is strongly typed, but it is not statically typed and types are not specified in method declarations. This dynamic nature is the source of both the power and the risk attached to using Ruby. What has been interesting me is whether there are useful parallels to be drawn between how individuals collaborate within successful teams and how objects should act in a successful dynamic language system.

See http://grahamis.com/blog/2008/01/03/ruby-is-strongly-typed-until-you-want-to-weaken-it/

The point of my article wasn’t to say that static typing is bad or dangerous (Jay did say that though), rather I was trying to see what is the best way to act sensibly and responsibly if you choose (or have been chosen) to work on a dynamic language. I actually think that as programmers we’re going to have to get used to coding in more languages as time goes on, so finding out how to be effective in a range of types of language is useful.

When I started writing Ruby I definitely missed some of the refactoring support I was used to in Eclipse - I felt like I was back in the 90’s with a text editor and javac … however now there’s not much I miss. I’m not going to make the argument that the “static type tax” of Java actually requires all the IDE support available just to make it usable, but I do find there’s a value in going back through your calling code when you’re refactoring to make sure you still understand how it’s used. So stepping through search & replace can be a useful activity.

There are also thing like structural subtyping and type inference which can be statically typed. They solve problem of cryptic generic annotations and large number of interfaces. Mainstream languages don’t support them yet but I think it’s a matter of time.