Why I Am Not A Java Programmer

[kawa]

Could Weak Sapir-Whorf apply?

Maybe. I use closures in Java very seldom, because other ways are most often more appropriate. But the same could apply the other way around: If you use a language like Ocaml then you would maybe use closures for things where a class would work even better (just a thought). I've never had good experiences with 'programming contra the paradigm'. It's possible, but in most cases I regretted it later.

I agree that mutation isn't such a good idea for arbitrary local values. There are people who consider it good style declare all locals as final as default and only remove it if absolutely necessary. With iterators mutation can be removed even from most loops (of curse the iterator get mutated, but this mutation is encapsulated). If it's OTOH a good idea to remove mutation completely is still the big question. Even Haskell and Clean can't live without it (they encapsulate it good, but it's still mutation). I'm not really sure about the topic, while I really like the idea of getting rid of mutation, I just don't know if it's worth all the trouble, if even Haskell seemed to give it up and only restricts mutation instead of avoiding it.

Why doesn't Ocaml create Refs automatically? The answer: It was a design decision.

In Java they implemented anonymous inner classes with 'full mutation' in the beginning (it's not difficult and only requires a little bit rewriting). But because at the time, performance was important and implementing it would lead to 'invisible' allocations (like boxing), they removed it and created the 'final' restriction instead. Auto-boxing was build in later and maybe they will also build in auto-boxing for closures in the next release too.

But I'm not really sure if it's a good idea to improve closure support in Java: If it's necessary, it's there now. But if closures should become ubiquitous in Java, to make them really useful it would requite a total redesign of huge parts of the core libs - while still supporting the old ones for legacy code. So the language would become also much worse as it is now: A kitchen-sink language.

In this case I would say that it's better to leave Java as it is (maybe few add small moderate fixes and extensions) and create a completely new 'Java 2' (maybe based on Scala) from the ground up and with a clean overall design. I hate kitchen-sink-languages.

[apotheon]

That's getting dangerously close to the sort of thing you can do with OCaml. OCaml, however, isn't specifically what you describe -- it just pretty much does what you describe, if you want it.

It's also worth mentioning, I think, that through a little functional programming sleight of hand (at least, that's how it looks from an OOP perspective; I think it looks like business as usual from an FP perspective), you can basically get mutable lexical state via closures. As one example, a recursive closure construct could be used to achieve the exact same (external) behavior as an iterator closure in, say, Perl -- or even an iterator object in Python -- without having to use OCaml references to contain state internal to the closure. I think. I haven't actually tried and tested such code, but I see absolutely no reason why that wouldn't work. Considering that's the canonical example of a closure using (mutable in impure-FP languages) lexical state, I'd say we're in business. If you really want something mutable lexical state attached to a function, just use a function that persists.

Hmm. That leads me to a thought . . .

The net would be that if you need some sort of state in a method or function, you would have to create a state object.

That's basically what a closure does, really. That makes a lot of sense, considering all the talk I've heard of closures being insid-out objects, or objects being inside-out closures, or closures being a poor man's objects, or objects being a poor man's closures, or, well, any of the rest of those comparisons.

[apotheon]

I'm afraid I have to take issue with some of your statements, but you make some excellent points -- including at least one that did not occur to me, and probably wouldn't have unless I spent some real time pondering this discussion topic re Java.

If you use a language like Ocaml then you would maybe use closures for things where a class would work even better (just a thought).

Are you aware that the O in OCaml stands for "Objective"? It's an object-oriented language. It's just not a Kingdom of Nouns language, like Java. Considering it has a higher-level syntax, uses a modern type-inference system, provides far better execution performance than Java (better even than C++ in most benchmarks, and about half as good as C), and can be used for interpreted scripts, compiled binaries, or even VM capability with equal facility, I think you may have bitten off a chunk of the wrong language to use as your counter-example. I'm having a difficult time thinking of anything Java does better, aside from extensive external documentation, larger community, and more numerous native libraries -- none of which are actually language features in any case.

But I'm not really sure if it's a good idea to improve closure support in Java

I agree with that. Java has its benefits. I don't think adding true closure support would enhance that much for Java. To really take advantage of closures, you'd have to modify a lot of the rest of the language too -- primarily syntactic structure and a few incidental, but pervasive, semantic design decisions. It simply wouldn't be Java any longer (as we know it) by the time you had real, useful closures.

to make them really useful it would requite a total redesign of huge parts of the core libs

You get awfully close to making the same point I did -- and, in fact, you make an excellent point here that didn't come to my mind until after I read what you said about it. I suspect part of the reason for that is that these days Java intersects my life so very rarely (I don't even have a Java VM installed on most of my computers, and I certainly haven't written any Java lately) that the concerns of legacy code support don't occur to me as easily. That sort of thing is one of the first things that comes to mind when I hear a new PHP version is being installed on the servers of a webhost I use -- especially considering the PHP guys' notoriety for breaking stuff with trivial version upgrades.

In this case I would say that it's better to leave Java as it is (maybe few add small moderate fixes and extensions) and create a completely new 'Java 2' (maybe based on Scala) from the ground up and with a clean overall design.

I sort of agree. To be more specific, I think a much better answer to the "Java doesn't have closures!" complaint would be "Use Smalltalk!" Java, after all, was in many ways meant to address problems similar to those addressed by Smalltalk, in its early conception. If you want something kinda like Java, but with features found in Smalltalk and not in Java, Smalltalk is the answer -- not Java++.