On Wed, Jun 15, 2011 at 1:06 PM, Reinier Zwitserloot <[email protected]>wrote:
> > I'm fairly sure that java.next needs to have something compelling. A > relatively small evolutionary step is not going to do the trick. If the C to > java exodus is any indication, we should NOT actually be looking at language > features / syntax, interestingly enough. What java had to offer at the > language level was virtually nothing. It was explicitly designed to be like > C, warts and all (that's the only explanation for postfix array brackets and > the switch statement), but it did offer things C just couldn't offer at the > time: Garbage Collection, a far more complete (and far more standard) > standard library, write once run anywhere, and the promise of sandboxing > (which I admit never quite panned out, but the promise was there). None of > these things are language syntax related. > I wouldn't go that far. At least for me, the syntax was a huge breath of fresh air after years spent wrestling with the darkest features of C++. I also remember finding the absence of headers unsettling at first, but I surprised myself at how quickly I got over it. The fact that I never had to say "new" and "delete" was indeed a big factor, and while it's technically due to the GC, it actually felt like it was more of a syntactic and thinking relief. This is an aspect of garbage collection that's often overlooked, by the way: its presence has a positive impact on both the runtime (no more memory leaks or crashes caused by referencing bad memory) *and* the source (no new/delete and the assorted headaches of figuring out when to free the memory). But there is an important lesson in Java's emergence: it succeeded not because it added more power but because it liberated programmers from tediousness. > - Modularization (in all dimensions), built right into the language. A mix > of OSGi (runtime modularization) and ivy/maven (build-time modularization), > coupled with *NO* standard library (everything is a module available on the > web, including the core libraries) > I think that would be a mistake. Standard libraries are critical for the initial success of a language. The initial libraries of Java were ridiculously bad, but the fact that they were shipped with the JDK empowered developers to prototype stuff right away and adopt a common vocabulary and patterns. In my opinion, a bad standard will always be better than no standard (see C++' continuous struggle with collections and threading...). The rest of your feature list looks pretty good to me. About your "pluggable compiler" item: I think that open types (à la Gosu) are very compelling, and also that the compiler should export the various phases of its compilation (especially a decorated AST) via a listener/bus mechanism. This will make tooling trivial (an omission that Scala is going to pay a very heavy price for, in my opinion). Compiler plug-ins should be allowed to modify these models but not alter the syntax of the language, or only do so with very clear syntactic flags (e.g. Java's annotations with their @ prefix). I think Groovy has made some pretty interesting progress in this direction. -- Cédric -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
