Tim Bray on closures

I read Tim Bray's blog posting on closures. What surprised me the most wasn't what he had to say about closures, but what he had to say about generics. He calls them a disaster. Which got me thinking a bit about my own experience with generics.

For the most part I actually like generics. It does away with a lot of awkward, boilerplate casting sillyness. Sure, it is syntactically displeasing as it gives me flashbacks of templatized C++ code (which I consider to be [insert favorite sequence of negative adjectives]), and it can make declarations quite chunky, but to be quite honest, I can't really think of a significantly better way to do it.

(Someone suggested a mechanism akin to typedefs, but I think that typedefs only makes code even harder to decipher. I've spent significant amounts of time trying to understand C++ code that someone else wrote, and people often make confusing, inconsistent use of typedefs in such a way that you have to be prepared to see the same type expressed in multiple ways throughout the code. I am generally not worried about a bit of extra typing. You can get around the extra typing by using sensible tools. The most important feature of code is readability and clarity).

Now, I was very happy with generics until one day, a friend of mine was showing me how awfully complex declarations some people on his project produced. I've been using generics for a few years now, and none of my code had declarations anywhere nearly as complex. I am not entirely sure what that means, but I am almost certain that it means some people are more willing to sacrifice clarity and simplicity for what they may see as supremely elegant genericity.

I appear to like generics used in moderation.

I think I feel the same way about closures and I think the reason why I am not too fond of the idea of adding closures to Java, as syntactic sugar: people are going to go apeshit and use them everywhere for everything. I'd rather be without them than to have to deal with code that adds another dimension of complexity by using a programming paradigm that can produce code that is hard to decipher.

I spent some time last year programming Ruby, and I can see what people like about closures. But I can also see how I might end up having to maintain code that is horribly convoluted and a lot more work than need be to understand properly.

If I were to complain about features that cropped up in Tiger, autoboxing would be high up on my list. Of course, I realize that ditching primitive types at this point would be a much more traumatic change than adding autoboxing, but I get this weird feeling of danger whenever I use autoboxing.

I know wishing for primitive types to go away in Java may be foolishly utopian. For all I know it may not even be possible without lots of trickery and it may give rise to whole new classes of ugly problems I am not aware of. But it I think I would like it.

No comments:

Post a Comment