All the Perl that's Practical to Extract and Report

I’m a lumberjack programmer and I’m okay

Aristotle on 2006-08-24T14:51:19

Mikael Grev:

Not only are the guys behind the Closure proposal [Ed.: for Java; see Gilad Bracha] very smart, they are also experts at what they do. Very probably the best in their field. They are also IMO very intelligent, which means they get the grasp of things very quickly, like most of the people hanging out here at [JavaLobby] I guess. The problem is that no one stands up for the normal, averagely smart “Java-Joe”. There is a simple reason for this. He does something else (like having a life, ;)) while we geeks are discussing closures and the fine print of the different syntaxes. The problem with this is that he neither have been involved in the construction of this “feature” nor has he even been asked whether it’s a thing he wants or solves any of the problems he has.

Closures will make the code harder to read. That’s a fact I think no one denies. […]

[…]

If we let experts design features for experts, no matter how clever these features are, we will alienate average Joe, and when he jumps ship, the experts will become average…

I don’t even know where to start. I’ll just keep the commentary short and biting:

  1. I hate people who trot out the “geeks who have no life” line. You do that, you’ve very nearly forfeited your argument on the spot as far as I’m concerned. All the geeks I know have a life aplenty.

  2. Closures will make code easier to read. Only the staunchly conservative Java guys argue against that.

  3. If closures are such a problem, why does Java have that baroque feature called anonymous inner classes, which roughly approximate closures? (Horrid syntactical overhead aside.) It has much the same cognitive cost, maybe even higher than closures, particularly considering all the weird special-case rules these inner classes follow.

  4. The byzantine systems built by people who have no passion or propensity for programming are legion. Such systems will be built by these people whatever language they use – even if it’s Sun’s Language Designed And Engineered For 9-To-5 Code Cogs. Why should the cogs’ limitations be a concern if that means constraining the most productive programmers from ever reaching their potential? There will always be 9-to-5 cogs, no matter the perceived complexity of the given language, anyway.

  5. I have absolutely no idea what his conclusion even means. Experts will become average? What?

  6. His fear of the masses of cogs jumping ship reminds me of that old bit of wisdom: First-rate mathematicians want to hang around first-rate mathematicians. Second-rate mathematicians want to hang around third-rate mathematicians.

Experts will become average

jordan on 2006-08-24T16:37:23

I think he means that the Expert Java Programmers will become the Average Java Programmers because all the rank-and-file will have abandoned Java.

Re:Experts will become average

jplindstrom on 2006-08-24T21:34:24

That sounds like it's either a good thing, or it really doesn't matter at all.

Re:Experts will become average

Aristotle on 2006-08-24T22:23:35

Well yes, that’s the letter of what he says. But what is it supposed to mean? He seems to imply it’s a bad thing somehow, as if the skills of expert Java programmers will diminish or something. That makes no sense.

His statement is either tautological or nonsensical.

Re:Experts will become average

jordan on 2006-08-26T19:23:45

I think he's expressing his concerns that the language will become a niche, of only interest to language experts.

I agree with many of your criticisms of his article, but I think he has a point that is well worth observing in some situations. Sometimes, language designers develop features to please themselves, with little attention to the needs of working programmers.

I think Hoare (?) observed this long ago stating that no language feature should be standardized until it gets significant practice behind it to back up it's usefullness. And yes, I do see a chicken-and-egg problem there.

pretty weak reasons

perrin on 2006-08-25T00:50:59

I do think closures are hard for many people to understand, based on the mistakes I see people make in Perl with them. However, Java inner classes are pretty awful too, possibly worse, and adding closures should not have any effect on people who don't choose to use them.

Probably the most reasonable argument to not put closures in Java is that Java is all about OO and closures are a different paradigm. If he argued that, I'd have more sympathy.

Re:pretty weak reasons

Aristotle on 2006-08-25T01:50:19

Yeah, I could see that argument. I don’t know if I’d agree with it, but at least it’s sound.

Re:pretty weak reasons

Adrian on 2006-08-25T08:58:07

I do think closures are hard for many people to understand, based on the mistakes I see people make in Perl with them.

I think it really depends on what you're used to and how you're taught. I've seen Lisp/Prolog coders having just as much trouble getting their heads around the OO approach. Closure style HOP code isn't harder - it's just sufficiently different that you actually have to learn it. (IMHO anyway :-)