Vale JCP?

Scala and Java:

By Rick Jelliffe
November 25, 2009 | Comments: 3

From ERH's Cafe au Lait:

So apparently Sun has decided to add closures to Java 7. They will, of course, not remove anything to make room, so Java just gets bigger and bulkier. They will also give us a half-hearted implementation that removes some interesting pieces that would make it backwards incompatible, so we're getting really aren't closures after all. Did Sun learn nothing from the generics debacle?

Most tellingly, despite all the talk of openness, this seems to very much be Sun's decision. There's no proposal in the JCP, and all discussion of this seems to have purely been internal to Sun. If you aren't eating lunch in the Sun cafeteria, you don't get to chime in. Sun simply presented the decision as a fait accompli to the community. First they decided they wouldn't do closures in Java 7; then they decided they would; and now they'll decide how and when. Scala's looking more attractive by the hour.

I am really impressed by Scala, though I have not used it on any real projects yet. Apart from reflection, it seems to be much stronger than Java in all the kinds of features that are good for XML document processing: co-routines, pattern matching and so on. The built-in XML tree that documents can be parsed in to does not contain back pointers, so up-going axes require extra coding; Scala is obviously more congenial for OmniMark or XSLT programmers than Java. Some of Scala is not well explained in the online documentation: the case enumerations for example: it seems that the purpose of this is to allow a compiler to complain when a switch is missing a case (very cool!)

My view of the continuation/closure debates is that they run the risk of substituting abstractions for features, to some extent. I don't want continuations per se, I don't want closures per se, I want coroutines or semi-coroutines.

And I want to be able to express them in a really direct processy way (UNIX shell pipes | comes to mind) not through some computer sciency abstraction. (I'd say the same issue arises with the way people talk about monoids in Scala: to some extent the purpose of a programming language should be to shield the programmer from the underlying abstractions, the user of a regex pattern matcher wants to match some characters, they should not need more than cursory knowledge of formal grammar theory in order to do so!)


You might also be interested in:

3 Comments

If you want coroutines you can build them on top of Scala's delimited continuations fairly straightforwardly,

http://old.nabble.com/Delimited-continuations-and-Scala-td22630026.html

Generators can be implemented similarly.

This is closures. As in "lambda expressions". Nothing to do with continuations.

Neal: As Wikipedia says "Closures are used to implement continuation passing style, and in this manner, hide state." So "nothing to do with" seems a little strong...

My point is expressing interest in a simple syntax/capability for semicoroutines, and my disinterest in more powerful and abstract mechanisms that might be foisted instead. I want a fancy yield() or suspend() which return a value, not some more elaborate mechanism couched in terms (or syntax, more particularly) of continuations and closures.

News Topics

Recommended for You

Got a Question?