The Black Hole Theory of Design

The past few weeks have been pretty entertaining: there's the final crunch to getting JDK6 out the door (with the side-thrill of coordinating with the tea-leaf-reading exercise that is Windows Vista), bringing closure to the open source debate, and the most fun: figuring out the plan for JDK7. This last is the geek version of writing up a Christmas Present wish list.

The list is mostly being put together by Danny Coward and Mark Reinhold, with a lot of kibbitzing from a cast of thousands. We do surveys of partners, fold in statistics from the bug voting system, stir up with our own opinions and then run the JCP debate.

There's an entertaining little firestorm going on over closures. Neal Gafter, Gilad Bracha, Peter Ahé and many more are fighting it out. The really heated debate is all in email and I'm incredibly far behind in reading it (by several hundred messages).

I have somewhat mixed feelings about closures: they are pretty complicated. But they're an instance of what I think of as the Black Hole Theory of Design. I have a really strong memory from years ago of Guy Steele saying roughly "Lisp is a Black Hole: if you try to design something that's not Lisp, but like Lisp, you'll find that the gravitational forces on the design will suck it into the Black Hole, and it will become Lisp". [Guy doesn't actually remember making this remark, but he does say it sounds like the kind of flip comment he would make; I could also be totally mis-remembering who said it, but I haven't found any quote like it through Google].

Closures feel to me like one of these design Black Holes. When inner classes were designed, we wanted to avoid the complexity of closures. But this brought about oddness and tension of it's own that has left me less than happy with inner classes. So, should we just give in to the force of gravity and go the rest of the way? The debate's afoot. It's going to be an entertaining year.

September 11, 2006