There are two things that are both java centric that are exciting and do not get in the way of java being the new C:
1. Add more language features that fit the general profile of java (so, nominal, manifest typed), and do not get in the way of allowing java to be the C of the JVM world. Closures are still a good idea, even if the java community has some difficulty getting to a consensus. It's okay if the closure proposal that does make it isn't quite as flexible as what other languages have to offer, but not doing it out of a stubborn refusal to work on java just because we've all accepted that its become the C of the world is a mistake. See the footnote. 2. Add more language features across the board - in Java (the language) And Java (The VM) which aren't so much programming language related (so nothing related to syntax, or closures, or dynamic invoke operators in Java the Language). Modularization is a fine example. One thing that no language I know of really did right, but which is very useful not just for java (the language) but for all languages that run on the VM, is a modularization system that allows near perfect backwards compatibility by offering libraries the opportunity to interpret their own old versions. Somehow. Or - working on profiling tools. footnote: There is no C VM. There isn't any language quite like C. There are no languages that give you the full power of C. That's why C is still around: If you need to write a device driver, for example - you use C. Or at least, that's what you did in the past 10 years. In the java world this isn't quite true: Making e.g. scala generate lean and mean class files isn't that difficult especially if you forego some of scala's niceties (such as the various hacks scala employs to get fast immutable lists). Java the language can't even generate all possible versions of class file: You cannot create methods that throw exceptions that you didn't declare you throw, whereas other languages can do that (the JVM doesn't have checked exceptions at all, only java- the-language does), and you can't create invokedynamic. In this sense, the concept that 'java is the C of the JVM' is just plain false. On Jan 22, 12:46 pm, Christian Catchpole <[email protected]> wrote: > If Java is the new C then how do we make it a better C. (I'm not > being sarcastic). If we don't want to go off on unpredictable > tangents with the language and change it's fundamental principals, > then perhaps we can concentrate on features which reduce our boiler > plate and reduces code size. > > How about a new shortcut definition for beans? > > public bean Thingy { > String name; > String value; > > } > > How about some way of doing delegation automatically? > > Perhaps we analyze where redundant boiler plate exists commonly and > find ways to short cut it, but be in the style of Java. > > We have discussed the chained 'returns this' method invocation - but I > still can't understand why people give that so much credibility. It > imposes strange behavior on an API for the sake of code density. When > a 'using' operator would perform the same function, globally and > backwards compatible. > > I had thought for a moment that we could create an operator to > shortcut reflection.. But the problem there I guess is that people > would actually use it (and abuse it). Or is this already coming with > involk dynamic? object->"method"(params, ... ); --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
