Hacker News Reader

Comment by whakojacko | Hacker News Reader

yea, that looks about right.

Everyone looking for these kind of features should probably just be using Scala...

While I would prefer Scala over [Java + closures], and would prefer Clojure over either of those, I am still pleased to see closures in Java for several reasons.

1) For now, I still have a job as a Java programmer. Closures in Java will save me some lines of code until I can fix that.

2) Currently each JVM language has its own incompatible reinvention of closures. I think that closures in Java are a step towards better interoperability between JVM languages.

3) A lot of programmers will be introduced to a higher level of abstraction than they otherwise would have.

> 2) Currently each JVM language has its own incompatible reinvention of closures.

Yeah, but as long as they expect Callables in the right place interop can be pretty easy with just interfaces. For instance, you can pass JRuby lambdas to Clojure functions just fine. Sure there's a duplication of effort, but it's not too bad for interop purposes.

How in the world do callables replace closures? Closures can have arguments, callables can't. You cannot pass a ruby lambda expecting arguments to Clojure.

> You cannot pass a ruby lambda expecting arguments to Clojure.

I beg to differ: http://github.com/technomancy/clojure-gem/blob/master/test/t...

Have you looked at the source code for that project? It doesn't use callables at all. the orig_commute function, the original commute method on class Ref, gets passed a monkey-patched ruby Proc object that implements the invoke method which takes one argument, a list, containing all of the original ruby arguments. Clojure then most likely calls invoke inside orig_commute through reflection. The end result: a bunch of hackery specific to Ruby and Clojure, something JVM-level closures would help eliminate.

Again, you cannot pass a ruby function expecting arguments to Clojure! What your link shows is that you can, however, send monkey-patched versions of ruby functions that implement clojure-specific calling conventions to clojure. :)

I noticed in the test code linked to by the article that the closed over variables are all declared final. I'm not sure if that's just because of the early stage of implementation or if that's actually going to be a requirement. If so that seems unfortunate and maybe an impediment to interoperability.

Closing only over final variables is deliberately a requirement because closing over non-final variables can lead to confusing situations. I discussed this in more detail in a previous thread:

http://news.ycombinator.com/item?id=1257599

Good point regarding the effect on interoperability. I don't have an answer for that.

Clojure is adding cool stuff of its own:

http://freegeek.in/blog/2010/05/clojure-protocols-datatypes-...

Look, I'm an independent programmer and I can pretty much chose everything about what I program in. Still, when it comes to completely new, and not very mission critical projects, I go for Clojure (still a bit green and unsure on my lipspy feet). When it comes to existing projects and serious stuff, Java is and Java will stay. Way too much code invested in it. I can and I do try to evolve my style and tools, but the one single thing that's always been in my way was a complete lack of higher order functions (anonymous classes are a verbose joke). So yeah, I'm ecstatic :)

Even if you do your project in Scala it is tremendously likely that you will be doing so on the back of a ton of Java infrastructure and you will have to interact with it intimately at times. If Java itself gets closures then (in time) we will get support for them in all the base Java APIs and 3rd party libraries and that will make them significantly more pleasant to use for everyone that is building on the JVM.

Reply on news.ycombinator.com