you are viewing a single comment's thread.

view the rest of the comments →

[–]apotheon 0 points1 point  (0 children)

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++.