(warning, this is long).
It's easier to invent a new language than improve the old one for the same reason it's far faster and cheaper to build a brand new road then to do minor repairs on an existing road that's *in use*. This is just the nature of software. Once something ships and is used by customers it instantly becomes legacy. And the more people use it the harder it becomes to change. Over the last 30 years of software development we've come up with lots of tricks to address this, but it's still a very hard problem with no easy answers. Why don't we step back and look at the big picture here. Java, the language, is used by somewhere between 4 and 8 million developers (depending on who's numbers you use). It's installed on nearly 1 billion desktop computers and even more servers and cellphones. In short, one of the most widely deployed software platforms ever. In short, something very powerful and valuable, but also very difficult to change. Every change you make to the core must consider the facts above, and that makes change difficult. Not impossible, but difficult and therefore cautious. For every person who wants to add a new feature there are 10 who want no new features (or at least different features). For every developer who wants to break backwards compatibility, there are 100 who don't. That's one of the reasons Swing has been so hard to evolve. I don't mean to sound depressing or to say that Java will never evolve. It will. But it will be slow. There will probably never be any radical changes to the Java language again. Nothing on the level of generics, at least. But you know what: that's okay. In fact, it might be a good thing! I was annoyed when I first came to this realization. I'm an uber-geek. I love to learn new things, build new programs, and try new paradigms. I'd love to see the Java language evolve with tons of new things. But after thinking and talking to a lot of people I also realized the value in the backward compatibility: stability. Java is a general purpose language that is becoming built into everything, and thanks to the compatibility promises it's enables tremendous portability and reliability. Libs from 10+ years ago will run flawlessly. This is incredibly valuable. It still sucks though. We have tension between evolving what we have and keeping valuable compatibility. Fortunately, we have an out: the JVM. The JVM is separate from the language and can host new languages which are compatible with it and with Java. This is incredibly useful. If you want to keep on the forefront then you can use a language with cool features like Scala or Groovy. If you need compatibility you stick with Java. And you can mix and match them at the class / jar level. This also frees the Java language to focus on compatibility even more, while freeing the new languages to innovate in new directions that wouldn't be possible with a mature general purpose programming language. The best of both worlds. I've said this a few times, but perhaps not here. Java, the platform, will be around for a very long time thanks to the separation of the JVM, the language, and the runtime. JVM bytecode will be running inside of our computers 40 years from now. Hopefully that bytecode won't have come from a Java compiler, but the reality is that some of it probably will be libraries we've been using for decades that still run great. That's the power of compatibility. And that's why Java, the language, must necessarily be slow to evolve. Now as for why JavaFX Script wasn't broader. It's mission has always been very constrained: to be the best damn language and API for building GUIs. No more and no less. Being focused results in higher quality and faster time to market. If JavaFX was more general it would be less good at being the best damn language for GUIs. - Josh On Sep 17, 2009, at 3:47 AM, Casper Bang wrote: > > I agree with your analysis although I often think of this as a > question. Why is it that it's ok to invent a totally new language but > shaping an existing one according to state-of-the art is not? It seems > like we are forced into making the hard choice between something > radically new (Scala, JavaFX) or legacy (Java). > > The only difference is that the radically new has no backwards > compatibility to worry about (yet). So how come we don't just evolve > the existing stuff and let go of some compatibility with the benefit > that you are offering the existing community a gradual and painless > transition (but forego backwards compatibility). It's not clear to me > why JavaFX was not made broader than it is, so it could effectively > function as such as replacement. > > /Casper > > On 17 Sep., 12:23, hlovatt <howard.lov...@gmail.com> wrote: >> You can see in this discussion group the tension between: "don't make >> changes" (Bob) and "lets keep advancing Java" (Reinier). I am in >> Reinier's camp, but think that both points of view can be satisfied >> with a source statement. If there is no source statement then the >> file >> compiles as it does now, but if the file has source "Java7"; at the >> start then you can use the new features and most importantly a file >> with source "Java7"; at the start does not have to be source >> compatible with current Java (though the two need to co-exist on the >> JVM - just like JavaFX and Java do today). >> >> This way everyone gets what they want. >> >> -- Howard. >> >> On Sep 17, 2:52 am, Bob Lee <crazybob...@gmail.com> wrote: >> >>> On Wed, Sep 16, 2009 at 12:59 PM, Reinier Zwitserloot >>> <reini...@gmail.com>wrote: >> >>>> There were a few proposals that didn't make it that >>>> nevertheless received some positive feedback and went through a >>>> bunch >>>> of iterations (case in point: Neal's exception handling proposal!), >>>> that were nevertheless not shortlisted. >> >>> You keep pointing to Neal's proposal, but one example doesn't >>> connote a >>> trend. Let Neal champion his own proposal. >> >>> While having a preliminary process might save some people some >>> time, it's >>> not something I'd spend time on. I doubt anyone else would either. >>> Frankly, >>> I hope the Java programming language *doesn't* change much more. I >>> certainly >>> don't want to do anything to encourage more change. In 5 years, >>> Java will >>> look a lot like C++, and we'll look back and say that we should >>> have just >>> stopped 5 years ago. >> >>> Bob > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
