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.

Programming language design and interaction/interface design are both activities concerned with designing interfaces between humans and computers. Even though there are many similarities, the two fields are generally very much apart. Extensive research and discourse exists about processes of designing human-computer interfaces in the HCI domain, much less so for language design.

In terms of programming language design, we could learn a lot by looking at the experiences and recommendations of HCI designers.

One of the fundamental rules of interface design is:

You are not your user.

This reminder really should be written on a large piece of paper and pinned to the office wall of every interaction designer. (Or at least of those who haven’t got it burned into the back of their retina already from staring at it for years.)

This statement aims to counter the most common fallacy in the design of user interfaces: that your shiny new, freshly designed interface is obviously good because you can use it without any problems. You find it really “intuitive” (I shudder when I only hear the word) and “easy to use”. But: You are not your user.

It is really easy to fall into this trap, but just like we as software engineers have accepted that testing does not prove the absence of errors, we need to internalise that the fact that we can comfortable use our own design proves nothing.

We are not our users. We design for others. So how then do you know whether others can use your design? Easy: you test it!

Sure, there are occasional cases of what’s called “genius design” – cases where one designer sits in a closed room, thinks very hard, and gets it right. These cases are sometimes wonderful, but also quite rare. For most cases, attempts at genius design fail. So, HCI as a discipline has developed a number of methods to arrive at good design more reliably. One of the popular methods is user centred design. And especially relevant in our context: user interface prototyping and testing.

Think about how the design of the Java language happens now. It is being designed through a community process. But that does not mean that it is designed by the community, and does not even guarantee that it is designed for the community.

Look at the diagram above. It shows, by my modest rough estimate, the population of Java programmers. Many people learn Java, many of those make it to become programmers. A few become experts. And then there are a very small number of real gurus. The most important part is: The great majority of programmers in practice are average programmers. Many will never make it to expert status, and almost none of us become gurus. For Java to work well as a tool, it must serve the average programmer. There’s your target user group.

The other important fact is: the design is done by the gurus.

Now, for user interface testing, you need to get users from your user group. Marc Rettig, in his excellent paper Prototyping For Tiny Fingers, for example, writes that ideally your test users should be the same people who will be using the final product. For the design of Java, there is a dangerous trap here. For programming language design, the designers are also users, since they themselves use the language. So it happens easily that they see themselves as the typical user.

Now, for good interface testing it is not only important to evaluate your design with real users, but the users also must be representative of the user population. And this is what the Java programmer diagram tries to tell us: The gurus are not the typical user. The fact that the gurus find something easy to understand proves nothing about the usability of the design.

Reading the BGGA closure proposal, I fear that the designers have fallen into a common design trap: designing for your own needs. They might be able to make good use of the new proposed features, but I have grave reservations about the rest of the developers. I am not convinced that the great bulk of developers will master the complexities of the proposal.

I get deeply worried when I read phrases in the BGGA proposal such as “…while the rules seem complex, function types do not add complexity to Java’s type system because function types and their subtype relations can be understood as a straightforward application of generics and wildcards (existing constructs).” When you actually look at the generics and wildcard constructs, there is very little “straightforward” about it for the average programmer. Here, the proposal clearly takes the view of the compiler writer and guru, and fails to realise the problems of the typical user.

Take the added syntax for example that enables every developer now to add what essentially amounts to custom made control structures. As far as my experience goes, that’s an invented requirement. While we were talking about making registering of listener methods easier, I think many developers were behind it. I have heard several say “Yeah, that would be nice”. But I have never once heard anyone say “I’d really like to be able to add my own control structures”. That was just not a requirement. But it’s in the proposal. Why? I get the unsettling feeling in my stomach that the answer might be “Because we can”.

I fear that the current proposal leads to many complexities that are beyond mastering for many average developers.

How much this is the case is an interesting question. I just said “I fear…”, which is no proof, not a statement of fact about the matter. And there is the problem. The examples the BGGA proponents like to present look quite nice. The examples Josh Bloch presented in his critique look scarily complex. Both camps now state that the other side just cherry picked extreme examples to get their point across. And my opinion adds just that – an opinion.

So how do we really find out who is right? The answer is in the HCI design process: we do real user tests.

We should take a prototype and get real, average users to work with it for six months, and have a proper evaluation to see what happens. We can find out whether people can really master it. And whether they find it useful. Not the experts, average users.

Rettig’s paper, mentioned above, tells us more about such tests: how to carry them out, and how to evaluate them. One of the most interesting things is his discussion of quick lo-fi prototypes for evaluation – maybe there is a possibility to have something similar with compilers. Have a mock up compiler that simulates the language so that it does not need to be fully implemented before testing.

I think it’s worth thinking about.

Is it worth the effort? Doing these tests properly will take months and require quite a bit of work. But think about the alternative: close your eyes, move forward and pray? What’s the cost if we get it wrong? The amount of damage created (in terms of the impact on the many thousands of developers who have to live with it, not to mention the work for all tool developers) is immense. It will define work with Java for many years to come. The impact is easily many orders of magnitude larger than the effort for testing.

So far, I have only talked about BGGA. I am not yet certain whether I am against any form of closures, or whether a smaller, more light weight approach (along the lines of the CICE proposal) could work. I have to invest more time to get my head around it. And I haven’t really looked at the other proposals – ARM and FCM – at all, so I cannot comment on those yet.

But for all of them, the same should apply:

You are not your user! Test with real users.

(And no, the JCP does not replace testing!)