Closures in Java 7: Not Likely | Hacker News Reader

Closures in Java 7: Not Likely

davidflanagan.com

30 pointsfogus21 comments

This highlights the difference between open and open.

java is technically open source, yet the decisions are made behind closed doors without any transparency.

And the standard open source response is "fork it". Are you prevented from building your own java with closure support and distributing it?

When ubuntu recently altered where window icons appear there was a lot of complaining even though linux is "open". Someone is in charge of all "open" projects and likely whatever decisions they make will upset some people.

It's actually difficult to get a fork of java going that people will actually use because of the technology compatibility kit. See here: http://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_...

"Are you prevented from building your own java with closure support and distributing it?"

I really hate this smug answer. At best it's naive.

Practically speaking I am prevented from doing that. I have two small children and a full time job. This leaves very little time for productive coding. Also, my expertise is not in VM implementation and design. I'm sure I could learn that stuff if I put my mind to it, if only I had a lot of free time which I don't.

Having said that, a real open source project is built around a community. Typically the community wants to have some visibility into the decision making process, and that simply isn't happening with the jvm imo. I don't think it's too much to ask of them to be open about an issue like closures rather than swinging from one side to the other seemingly at the whim of a few people without any explanation.

" yet the decisions are made behind closed doors without any transparency"

care to explain who are these decision makers? Given the JSR and other process, curious to know who makes these hidden decisions.

Given the lack of JSRs filed for Java SE 7, the decision makers appear to be employees of Oracle (previously Sun).

Take closures for example. We were told they weren't going into java 7. Then at that one presentation on fork/join we were suddenly told they were going in. There was never much explanation behind the bipolar decision making.

This is not transparency, it's the whims of a small cabal.

I think "Java 7: Not Likely" will be the next news. The fact that the only people excited about it are non-Java JVM users should reveal something.

Speaking as someone whose current long-term main project is Java-based: Java's development has stalled. Go and learn Scala, Clojure, Python, Haskell, <brand x>. (Note that is not to say that you need to abandon whatever Java you're working on, just that Java's pain points getting fixed looks very unlikely.)

Working on it. But it's the steepest learning curve since I learned to program the first time.

It almost feels as though already being able to program is actually a hindrance.

"It almost feels as though already being able to program is actually a hindrance."

Hmm , that's interesting i faced the same problem.

Fwiw , here is a technique i use to ease the learning curve. I picked up a light-weight project - Lancet from Stu Holloway's book. Following the book, i wrote all the code tasks given there in the known language (Java or Python)- to understand the problem- and then transcribed it into Clojure. Initially it was really bad non-idiomatic Clojure , i was aware of this but would consciously only aim to finish the task. This gave me some confidence, made me "think" in Clojure and allowed me to learn some of the clojure libraries. I have finished the book.

Now, i am looking at the clojure-contrib code and discovering/learning idiomatic Clojure and going back to my Clojure code and changing that to be more idiomatic. This time i don't need Java code to actually understand the problem. Hopefully, at the end of this cycle i will be a little better.

I also found that knowing programming language fundamentals helps a little but only in the abstract , it doesn't help in being fluent in a language.

I've had the learning curve problem as well. So far the resource which has most helped ease the curve is http://clojure-notes.rubylearning.org/. If you have/find anything better let me know.

Take a look here:

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

Which? Scala, Clojure, Haskell ...?

Clojure.

This has been my experience too. I found CL, Scheme, and Haskell pretty easy. Clojure has taken me more time. I think it's because there aren't many good books yet, and because Lisp-speaking émigrés have to learn a set of new ideas that's mostly separate from the new ideas Ruby/Python/Java users need to learn.

What specifically has been giving you trouble?

That there is no side-by-side comparison of how a seasoned 'imperative' programmer would set up a fair sized website (not some toy), so something with user authentication, database access, templates and some serious business logic and internationalization compared to how you'd tackle the problem in clojure, functional style.

Then I'd be able to take a section from the one, compare how the 'natives' get the same effect on the other side of the line.

It would be nice to have a 'reference' website that gets ported to every language that is used in a web context following best practices for that language/environment.

That way you'd already understand the problem they're trying to solve and you can concentrate on how it is solved.

Hear, hear. I am quite at the point where I play too much with Python's itertools and want a more pure language - but Clojure is seriously unhelpful in telling you how to actually construct any Clojuriffic code.

That's Oracle for you. In the end the only way for the JVM environment to advance would be if large users of the JVM push for new features until the FOSS community forks and begins patching up.

I'm more disappointed that continuations don't appear to have made it. They're available as a patch, but actually compiling an OpenJDK with them is evidently an arcane art I haven't yet mastered.

If you're still interested in closures for Java, my port of Ruby's Enumerable module, Enumerable.java, has a limited version for valid Java 5. The current release is 0.2.4, but this post is the best introduction: http://www.jroller.com/ghettoJedi/entry/closures_in_valid_ja...

Reply on news.ycombinator.com