Growing pains around Java 5

ziggy on 2004-07-21T13:40:18

Ted Leung went to a Java Users group meeting last night, where the discussion was about the recent JavaOne, and Sun's forthcoming update to the Java Langauge (Java 1.5; the "1." is silent, as it was with 1.2). Ted notes:

There was some feeling that Java 5 was going to create two languages, pre Java 5 and Java 5. The fact that many of the new JSR's are already incorporating generics and attributes will only strengthen that separation.
Hm. Sounds familiar. Then there's this tidbit:
Java programmers are going to have a lot to swallow over the coming years. The good news for them is that C# isn't any better. C# already has annotations (attributes) and is about to add generics, so the two languages are remaining essentially equivalent.
This is sounding more and more like a seismic shift in programming language design. We're all agreed that garbage collection, objects and even regexes are good. Now everyone is going back to shoehorn generics and attributes.

I'm taking bets on when languages like Java and C# get real closures, macros and continuations. ;-)


GC

djberg96 on 2004-07-21T14:49:15

I'm taking bets on when languages like Java and C# get real closures, macros and continuations

Bruce Eckel mentioned in his talk that C++ is planning on adding garbage collection!

"Closures, macros, and continuations"

educated_foo on 2004-07-21T17:17:02

I get the feeling many people just lump these three things together because (1) Scheme has them, and (2) Scheme is the standard place to look for non-painful programming language research. But really, it's probably best to keep them separate.

Closures are widely useful even when, as in Java, they must be disguised as "inner classes". Macros are cool, but hard to pull off usefully in a syntactically-interesting language (I haven't really programmed in Dylan or OCaml, but both have macros without Lisp syntax). Continuations, on the other hand, aren't IMHO widely useful, and place constraints on the implementation that limit its performance. For example, Bigloo by default doesn't support call/cc, because doing so slows down the generated code. I'm sure not holding my breath for someone to propose continuations in C++ or C#, other than as a blecherously cool hack...

Re:"Closures, macros, and continuations"

ziggy on 2004-07-21T17:33:12

Sure, Java inner classes are effectively closures, but they are much more painful than lambdas in Scheme or even closures in Perl. And, due to the nature of the inner class model/syntax, it is much more complicated to wrap a closure within a closure in Java. For example, memoization is a trivial hack in Perl, but I don't want to think about how to do it with inner classes...

As far as macros go, there are two issues here: extending the language with new primitives (up to and including new control structures), and creating code dynamically. You don't need a full blown macro system to get the second, since Perl can automatically create subs, objects and classes dynamically at runtime (e.g. when a module loads itself). I would assert that's where the biggest win is.

Continuations? I'm not entirely convinced that they're very useful either. But then I said the same thing about closures 15 years ago. ;-)