Martin's statement that defines the debate clearly shows his bias towards the Humane argument.
Minimalists tend to focus on the minimal set of necessary methods to support these behaviors, humane designers try to add methods that are needed. Often these extra methods are referred to as convenience methods, a term that minimalists do not consider to be a complement.This statement is followed up by two examples taken from a comparison of the first, last and flatten methods found in Ruby's Array class that are not found in Java's List Interface. In the counter arguement against, Rusty uses some words that should be familiar to Martin.
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 minimalist argument is that List (or Array) doesn’t *need* a first or last because that functionality is already contained in the get(int index) method. Further more the existence of a method to flatten an array of arrays would seem quite frivolous to a minimalist. After all, when is the last time that you honestly remember needing to flatten and array of arrays (or list or lists). This example clearly shows the distance between the two positions.
This distinction in wasn’t lost on the blogging community as many people jumped on the bandwagon. Not surprisingly many of those blogs were centralist as they failed to fully support either position. However the futility of the debate is questioned in a very thoughtful blog written by John D. Mitchell.
Alas, arguing back and forth over those sorts of details makes it easy to miss a fundamental, crucial point: no software (library, application, language, operating system, or whatever) can be all things to all people. Fighting that war is not only pointless but is one of my definitions of insanity. The point of a chunk of good software is to enable the effective and efficient creation of more good software and to help inhibit the creation of bad software.Does all of this mean that one of our leading thought leaders turned a complete 180 on his previous musing on interface design?