Maybe Java development does rot the brain - have a look at this screed from Cafe au Lait against Martin Fowler. Martin says the following about Ruby's List class (and the same things could be said about Smalltalk's List class):

The obvious contrast to a minimal interface is that humane interfaces tend to be much larger, and indeed humane interface designers don't worry too much about the interface being big. This isn't to say that classes with humane interfaces need be larger in terms of implementation. The fundamental functionality of the two is often quite similar.

A good way of looking at the difference between humane and minimal interfaces is to compare the list components in Java and Ruby. Java has an interface (java.util.List) which declares 25 instance methods. Ruby has an Array class (which is a list not an array) that has 78 methods. That difference in size is something of a clue of that there's a different style here. Both components offer the basic same service, but Ruby's array includes a lot of additional functionality. This functionality is all relatively small things that can be built on Java's minimal interface.

Seems reasonable to me - one of Martin's examples is that Ruby (and Smalltalk) have #first and #last methods. So with a Ruby collections, you can do this:

aList.last

Whereas in Java, you have to do this:

aList.get(aList.size -1)

The response from Cafe au Lait on this is just stunning:

A 78 method List class is about three times as bad as a 25 method List class, not three times as good. A 12 method List class would be about twice as good. Simplicity is a virtue for both users and implementers. There's simply no reason for 78 methods in a basic List class. In fact, there's no reason for 78 public methods in any class. 78 public methods in one class is a code smell. 78 public methods make a class hard to learn, hard to use, hard to test, and hard to maintain. When a class has 78 public methods, it's time to refactor.

The raw number of methods tells us nothing about whether we need to refactor or not; we would have to actually look at the methods, and see if any of them don't fit. However, that's not his objection; he's very worried about all these methods - he really, really wants his classes to be sparse. For instance:

Fowler likes the first and last methods in Ruby, but list.first() is not significantly simpler than list.get(0). list.last() is perhaps a little simpler than list.get(list.size() - 1) but only because Java stupidly indexes everything from 0 rather than 1. And how often do you actually need to get the first item in the list? Needing the last item in a list is even less common. Normally the reason we have a list in the first place is so we can iterate through it using an Iterator or foreach. More often than not no single element -- first, last, or middle -- is explicitly identified in the code. Java's List class does not lack any of the functionality in Ruby's. Java just factors it out into a few more classes, especially the Collections class, and skips a couple of rarely used "convenience" methods. The result is a simpler, easier-to-understand, easier-to-use, more humane API.

Umm, yeah. It's so much simpler to write extra code every time. I suppose that showing this guy the four search methods in Smalltalk's collection classes (which I'm sure Ruby has as well) - #select: , #detect: , #reject: , #collect: would just make his head explode.

I use #first all the time, btw, and I use #last a fair bit as well. Perhaps Java developers don't simply due to their absence? It can be hard to miss what's not provided.

This isn't the first time I've seen this reaction. If I recall, Java's Object class has something like 11 methods. A base VisualWorks image? Object has 235 mthods. I've seen Java guys recoil in horror over that, ranting about the horrid OO design. Funny how Smalltalkers have gotten by for over 25 years this way.

There seems to be a general desire for sparseness in Java-ville. It's a value that neither Smalltalkers nor Rubyists seem to worry over. We are far more interested in solving application problems than we are in the production of extra code to support sparseness.

Update: More from Cees de Groot. And make sure to follow the comments link for more.