Java (.Net) Style vs Smalltalk (Ruby) Style

originally here, with answers/comments here and here.

Well I think that both parties are wrong/right.

78 Methods is a little bit too much, but in Smalltalk the Classes are extended and I believe that the 437 methods for the Object class are meant to be there. (And not in the Object-Utilities class like the C#3.0 way).

Second to that, you *must* love the way methods/classes can be categorized in Smalltalk.
It's like a quick-sort for my eyes, tired of scroll-down, scroll-down.

I must go back to C#: actually the whole "utilities" stuff, in the C#3.0 is a hack for extending/categorizing classes and methods. We will have: Object-Xml-Utilities, Object-JSON-Utilities and lots and lots of other Utilities (or Categories !?).

3rd, access by index in a List is wrong !!! The whole concept of hiding the implemetation has vanished. I don't want to write list.get(list.size() - 1) !!! This is clearly a code-smell. All the references in the code snippet are to the list, so the list should/must contain the method which wraps this code snippet , i.e. list.last() method.

Some really nice metaphors:

The cell phone is a great mental model for how to design a class. You just punch in the number of the person you want to speak to, and the phone takes care of the rest. You don't need to know anything at all about how the cell network operates, how it interfaces to the land-line system, or anything else for that matter, to complete your call. The phone is a black box with an intention revealing API.
[isomer]

Alan Kay has lamented publicly on more than one occasion that he should have called it Message Oriented programming to drive home the idea that designing the correct messages is of paramount importance.

With bitterness: "The only thing we learned from history is that we did not learn anything from history."

ps.

But there's more wrong with the collections in Java: optional methods Which means the implementation may or may not support the method. This is one of the benefits of static typing. You know at compiletime that the instance will have the method.

The same disease has the .Net Framework. Just look at the IList implementation of the Array.
"... Always throws NotSupportedException". The class Array is clearly lying about fulfilling its contract, to implement IList interface. What are the benefits of static-typing in this case, compare to dynamic typing + #messageNotUnderstood?