Over the last couple of weeks, I have started to look in more detail into the proposals for adding closures to the Java language. The most discussed proposal right now is the BGGA proposal, so I’ve been concentrating on that one first.
To say it up front: I have always had some doubts about adding closures to Java, but with this proposal I am firmly in the “contra” camp.
I had originally intended to write up my views of the proposal here, and the problems I see with it, but I don’t think that is necessary in detail anymore. Several other people have recently done this.
If you’re new to this debate, I suggest you start by reading some of the following: There is, firstly, the original BGGA Closures proposal, Josh Bloch’s The Closures Controversy talk, in which he discusses some of the problems, and Neil Gafter’s response to Josh’s presentation.
And now there are two very nice commentaries, one by Bharath, and one by Tim Bray, both of which I very much agree with.
So, instead of repeating their arguments, I’d just like to add one different aspect to this debate: Looking at the Java Language design from an HCI perspective.
Doing user support can be a bit tiring sometimes. Then again, sometimes it can be funny.
We all have problems with software sometimes, and it is good if you can mail some support person to get some help. In our development team, we get quite a bit of mail from our users. But obviously, some users are better at asking questions than others.
Should you ever find yourself in the situation where you need to ask a question, maybe it will help to keep the following examples in mind.
Here are some of my favourite user questions and comments from the last few years.
Recently, I wrote a blog post titled “Can Java be saved from death by feature bloat?“, that commented on some of the feature proposals for Java 7 (and some existing ones).
This post generated many comments. Some of them are so stupid, that I feel compelled to respond.
What I really want to get across with this is: I really like Java. It’s a great language, and most of the language zealots haven’t got a clue what they’re talking about.
We all agree that Java needs simplicity – we just don’t agree what that means.
Several things came together recently that made me think about simplicity in the Java language again, and what that might mean. And one thing is clear: simplicity is not simple!
Events that prompt me to write about this again were feedback I recently received about another blog entry (where I discussed simplicity in more general terms), a discussion by the Java Posse guys about new language features, and my own teaching. (First term is about to draw to a close in our parts of the world, so I’ve just been through 12 weeks of teaching another cohort of freshmen programming in Java again.)
The executive summary is: I think many of the recent discussions for changes to Java are in danger of pulling the language downhill fast, and the term “Simplicity” has different meaning to different people that cause directly contradictory results for language design.