This might make sense for Clojure (I haven't used it) but in my years of Ruby programming (after 10 years in Java and C#) I have never thought to myself, man I'd love to have an interface here. Ruby's lack of class-level contracts is essential to its idiomatic nature, a strength not a weakness, imo.
This is short-sighted. The key point in your statement is "I". Contracts are not about "I". They are about everyone else. You have a great design and interfaces allow you to share that.
This simply makes no sense in a Ruby idiom (and I'm not really sure this is the best way to think of it in Java either -- I can make an API public and well-documented with or without interfaces.)
I've used dozens of Ruby gems, plugins and classes over the years that have well-documented shared APIs and none of them (obviously) have had interfaces. Interfaces are good in certain environments for hiding implementation details where class-level contracts are enforced, but in Ruby this would provide no benefit at all.
Think of it this way: since Ruby has no class-level contracts, to some extent everything is already an interface. Everything is abstract. Every Ruby object has the opportunity to re-implement functionality in an abstract way.
Generally speaking I like interfaces, but Ruby is so dynamic that you couldn't use them for compile-time guarantees. Interfaces could only get you a slightly nicer way of dynamic duck typing. I wouldn't really call all of the dynamism a strength though - one of the limiting factors of compile time evaluation here is that a method can later become undefined- when is the last time you needed that?
Actually, undefining methods on an object because such an idiom that Ruby 1.9 introduced a new base class into the hierarchy: BasicObject. [1] This is now the new root class, above Object.
Yeah, that is the 1 case, and ActiveSupport has had a BasicObject for a while now. This is another case where proponents would say it is great that you can undefine a method, but I would say that is a hack for lack of any namespace management. Now that there is a BasicObject I am not sure that there is any practical use for undefining a method- probably only for dealing with namespace collisions, which again seems to point out a language flaw, not a feature of dynamism.
