I guess i wasn't very focused in yesterday's entry, paying too much attention to the details of the specific puzzle and not emphasizing my main point (or as Chris defined it the "money quote"). I'll try to rectify it here, bringing together my thoughts on the subject of evolving Java as a language.
First, let's start with the code from Neal's entry. Here is the relevant part:
static <T,U> List<U> map(List<T> list,
{T=>U} transform) {
List<U> result = new ArrayList<U>(list.size());
for (T t : list) {
result.add(transform.invoke(t));
}
return result;
}
public static void main(String[] args) {
List<Color> colors = map(Arrays.asList(
Flavor.values()), { Flavor f => f.color });
System.out.println(colors.equals(Arrays.asList(Color.values())));
}
Putting aside the puzzle punchline, here is how i would do the same without closures:
public class Puzzler<T, U> {
interface Transformer<T, U> {
U transform(T t);
}
List<U> transform(List<T> list,
Transformer<T, U> transformer) {
List<U> result = new ArrayList<U>(list.size());
for (T t : list) {
result.add(transformer.transform(t));
}
return result;
}
public static void main(String[] args) {
List<Colour> colors = new Puzzler<Flavor, Colour>().transform(Arrays
.asList(Flavor.values()), new Transformer<Flavor, Colour>() {
public Colour transform(Flavor f) {
return f.color;
}
});
System.out.println(colors.equals(Arrays.asList(Colour.values())));
}
}
And now comes the million dollar question - which one is better? It's a simple question that has two straightforward answers. However, the real answer is "it depends". And based on the subjective background of each one of us, we would go for either the first version or the second version. What does it depend on? Well, quite a few things.
There was an illuminating exchange of opinions in Scala blogosphere about a month ago, ignited by Doug Pardee's post, which lead Reg Braithwaite to quote Jef Raskin's views on the definition of intuitive:
It is clear that a user interface feature is "intuitive" insofar as it resembles or is identical to something the user has already learned. In short, "intuitive" in this context is an almost exact synonym of "familiar."
Let's get back to our two code samples, and to the question which one is better. In my highly subjective opinion, the second one is better, because:
- it is more readable
- it is more maintainable
- it is more verbose
Allow me to address each one of these three points. The second sample is more readable because this is how i'm accustomed to program this sort of requirement. This is what the current language structures allow me to do, and i don't find it too much of a hassle. The code is more maintainable because of the limited variety of currently available options. It ascertains that i and other people who will have to maintain this code must have seen this approach a few times in the existing code base. Getting back to the Jef Raskin quote, it feels more intuitive since it is familiar. Not necessarily optimal, but familiar nonetheless.
The last point on verbosity might be a little controversial, but i'll stand by my words. I've programmed in Ada for almost five years (professionally) and i've never seen it as an over-verbose language. Sure, it might take me an extra 20 seconds to read through the definition of that interface and its invocation, but the extra verbosity makes sure that the code guides me (as its maintainer) along its intended path.
Why would one choose the first example? There are many reasons, all of them undoubtedly valid in the subjective eye of the relevant parties. Some would enjoy the perceived expressiveness (cramming more logic in less characters), some would prefer the abstraction of a method body as first-class language citizen, some would want to know that their language is on par with the hot kid-du-jour that gets all the blogosphere love, some would view it as a refreshing exercise to expand their mind, and some would see the commercial potential that lies in books, consulting and conferences (absolutely no offense meant).
One nagging question remains unanswered - who is the intended target of the new language features? Are the creative minds behind different closures proposals at work just because they are creative, or is there an overwhelming evidence that Java programs (and programmers to a lesser extent) suffer without this language feature. Couple that with the absolute refusal to remove existing language features (like, say, poorly-implemented generics), and you get the following from Bruce Eckel:
But we need to become especially conservative when considering major, fundamental language features like closures which, while they can be very appealing in theory, may have a cost that is too great in practice when they are forced into a language that values backward compatibility over the clarity of its abstractions.
There are real-life scenarios addressed by closures. Anonymous listeners, unnecessary complex try-catch-finally blocks on closing streams and connections, blocks guarded by semaphores, you name it. But if the language is not going to remove (refuse to compile) the existing ways of addressing these scenarios, adding yet another way to do what millions (yes, millions that do not read or write blogs) Java programmers already know how to do is very harmful. Harmful to the code readability (at least in the first few years with the very slow adoption rate for the server-side JDK upgrades) and harmful to the code maintainability.
In my opinion, the language is only a tool. At the end of the day, we still have real people addressing real problems. The technical merits of new language proposals need to be weighed carefully against the potential negative disruption that they bring into the everyday cycle of software development. The puzzlers are only a tip of the iceberg. When i need to maintain and extend existing code, i already have a hard enough time to understand the business logic in it. If you're not going to remove the existing ways to address the limitations imposed by the language, don't add yet another way. It's not going to help me. Not in the everyday world.
]]>
]]>
