Java people are funny 1
Sometimes you have to laugh. Or cry, I suppose.
Martin Fowler has somehow sparked off a wide ranging argument that appears to be heading rapidly Hitlerwards. And all he did was write about the tension between Humane and Minimal interfaces and then confess that he tended to the humane side.
Me? I’m a fully paid up member of the Humane society. I’m longtime Perl programmer — it comes with the territory. Just read Larry’s piece about The first postmodern language from 1999 or any of his States of the Onion for reasons why.
I read Martin’s piece with a faint sense of “Hang on, haven’t I already said that?” but, on trawling back through my archive I see that, whilst I’ve certainly thought it on many occasions and said similar things over drinks with other programmers, I’ve never written anything about it.
I don’t know why it should be, but most of the sound and fury that’s resulted from Martin’s eminently sensible post has revolved around Ruby’s Array#last method. The minimalists claim that everyone should simply use (um… hang on… I’ve got to go and look this up) list.get(list.size() - 1).
The problem is that Java itself is an inhumane language. My reaction, as someone used to the Smalltalk and Ruby1 way with objects is to think “Well, I keep doing that list.get(list.size() - 1) thing, I should turn it into a method somewhere. I’ll call it last. So where should it go? Well, the only argument it needs is the list itself, so it belongs in the List class.” And here’s where Java falls down, because you simply can’t do that. You have to stash it somewhere else. Or, more likely, you don’t stash it anywhere ‘cos, well, it doesn’t take long to type.
The damage that this sort of thing does is subtle, but as usual, Kent Beck has already explained it well in Smalltalk Best Practice Patterns. The goal is to factor code so that each method works at a consistent level of abstraction. So, if you’re writing a method which2 grabs the first and last elements from a list and then does stuff with them then list.get(list.size() - 1) has the effect of pulling the reader away from what the current method is doing to the nuts and bolts of the list implementation. It’s not a huge distraction, but still… So, get rid of it and use list.last instead. Now you’ve got list.last, it seems a little strange to be using list[0] to get the first element, it’s a smaller distraction than the snippet for finding the last element, but now it’s inconsistent: list.first it is.
Simple changes, but when you start to add them up, they pay dividends in readability. I don’t know about you, but I always try to optimize for readability. One spends so much more time reading code than writing it.
And who knows, in the future, you might find yourself passing a Range into that very same method. Because you’ve used abstract accessors rather than data structure specific accessors there should be no problem.
Dynamic languages with open classes encourage this style of programming. Another great example of the power of humane interfaces and how they reinforce and are reinforced by other strengths of dynamic languages is the Integer class. Ruby’s Integer class is almost naked compared to its Smalltalk equivalent3, but there’s still something rather satisfying about writing 10.downto(1) {|i| ... } or 7.times {|i| ... }. It sure beats having to decode the standard for(i=0; i<10; i++) {...} thing. I’m not even sure I’ve got the arguments the right way round, it’s been so long since I had to use one. Not much use to a Java programmer of course, but if you will go programming in a language without first class blocks what do you expect?
Humane programming falls out of the Smalltalk Way — another of the consequences of objects everywhere and rigorous attention to putting behaviour in the right place.
Another objection that crops up in the discussion is the argument that the typical humane trick of having multiple methods that do the same thing is that this violates the DRY principle. Well, up to a point. The thing to remember is that, although two methods may do the same thing, they are often used in very different ways. By giving a behaviour multiple names you are, in effect, saying that the important thing to express is the intent of the programmer using the method. Inhumane Minimal interfaces are a denial of this in favour of making the library programmer’s life a little easier.
The great thing about a dynamic language is that you can take a class family with a minimal interface and simply add new methods to the class to humanize it.
1 And Perl 6.
2 I just havered over whether to use ‘that’ or ‘which’. British English usage tends to be to choose one or the other based on how the sentence sounds. Rather like choosing between Array#size and Array#length in Ruby really.
3 I just fired up Squeak to have a look. Ruby’s Integer has 13 instance methods apart from the ones it inherits from Numeric. Squeak’s instance methods are divided up into 16 protocols (think del.icio.us tags for methods or, in Smalltalk parlance, message selectors)
This was one of the most sensible comments in that absurd discussion, but it still misses the point that the Ruby Array methods are applicable to arrays in the scripting language. Ruby has Array#pack because Perl has pack(). The criteria for Array are completely and utterly different from the criteria for designing contain class libraries (which are in turn are significantly different from the criteria for designing application classes). Martin Fowler should be ashamed for picking such an incredibly bad example.