Marin Fowler raised quite the storm with a rather modest post about humane interfaces, which was responded most notably with a critique from a Java guy, and a counter from the Smalltalk guy. But I think the Java guy has a point: 78 methods on your list objects isn't good. Less methods is good. Unless the result is stupid. Now, let's be honest here, Java is stupid. Dumb, idiotic, maybe written by people who aren't programmers; I just don't know how else to make sense of it. list.get(list.size() - 1) should be embarrassing. list.last or list[-1]? I think [-1] reads well enough, and fits into a very elegant set of functionality involving slices and whatnot. But I also think list.last is entirely justifiable. OTOH, list.get(0) isn't embarrassing, so list.first isn't as compelling. And the nitems method he points to really seems overboard. There needs to be a limit somewhere. 2.years + 3.days ... I don't know if I can really get behind that (BTW, that's not built in to Ruby, but it can be extended to do that).

Maybe an interesting parallel is 0 vs. 1 indexing. 1 clearly seems more humane. I personally count starting from 1. I'm naturally inclined to index from 1. Languages go both ways on the choice.

But, while 1 indexing is more humane, 0 indexing is consistent with a set of useful properties. Programming is both narrative and mathematics, and when the two are in conflict it's hard to say which one is right. But experience can tell us which is right. 0 is right.

Mathematicians are inclined towards minimalism. But mere minimalism does not make something mathematically sound or reasonable. Mathematics is a sensible argument for 0 indexing. But mathematics has nothing to say about the number of methods on containers.

Not accounting for good container handling in your language is stupid. Stupid, stupid, stupid. If you are clever, you can make it seem like container handling just falls out of your more fundamental

constructs. Smalltalk does this well. But don't be fooled -- a otherwise similarly elegent system that didn't work well with containers would have been discarded. The Smalltalk designers were playing the same tricks mathematicians play; when you look at a mathematic proof you think how elegent, how simple, and how indecipherably attained. If I strive for simplicity, work from just a few axioms, will I achieve the same thing? No! Because there's lots of notes and failed attempts and crude proofs the mathematician didn't show you (it would be fascinating to see what Smalltalk 76 actually looked like). Java is like someone looking at a proof and thinking that they will write down theorems starting from simple axioms and get something good out of the other end. But they didn't realize that the (talented) mathematician deduces an interesting outcome and creates the proof as a bridge to that outcome. Missing this, the Java designers created something stupid and crude. They created something that had all the trappings of good design, with none of the outcomes that drive good designers.

Of course Smalltalk indexes from 1, so no one gets everything right.