To Josh, Bob, and all the other 'java is a fossil' arguers: Please, stop.
Your argument fails almost immediately: Because the JVM has no notion of a closure, a 'duration' type, and a gazillion other things various new JVM languages are trying to add (as discussed in posse #278!), interop between them is much, much worse than dealing with java (the language)'s ideosyncracies. Fan even attempts to invent a completely new library to go along with it. Talk about a learning curve! (so does scala, for that matter. Will noop?). Interop between the new language and java is similarly useless. Again, refer to the posse episode, where the act of trying to interop javafx with java on anything but the highest level was strongly discouraged, and for good reason. Without that interop, your entire argument boils down to: Everyone is supposed to at some point either rewrite their project FROM SCRATCH into a new language, or migrate slowly by starting new projects in a new language, and continuing to maintain the older projects in java. This feels like a bad idea. Scratch that, a horrible idea. Even if we accept java as a fossil, it'll first have to evolve towards being more interop-compatible so we can all move away from java in an orderly fashion. I'm confused, too: You're all the kinds of geek that care about this sort of thing, so why is everyone just silently accepting the axioma you've posited here: ALL LANGUAGES DIE - that's what you're saying. At some point the userbase enforces strict backwards compatibility, and somehow we've gone from that to - language dies. Hold on. We're skipping way too many steps here. Says who? Why can't java evolve AND stay backwards compatible? We've got 3 things, all named java: - The JVM (lots of work, but it can and has been evolving, and nobody seems to be asking for it to stop) - The core libraries (lots of work. Evolving it is very hard, and backwards compatibility constraints are choking improvements) - The langtools project (Compared to the other two not even a drop in the water. evolving a little, but this is really the entire focus of coin, lombok, and other attempts to continue evolve the java _language_). As the JVM is already evolving, that problem already solved itself. Moving on to how to evolve the latter two without breaking old stuff: For the core libraries, it's hard, but handwaving java (the language) away as a fossil does not make this problem go away. For interop, we NEED to add closure types and other primitives to the core. To keep the core clean (unless everyone really feels fans and scala's approach of writing wrappers on top of everything is a solid plan - where does that stop? Will we have 8 layers of wrapper in 2020?) we need a way to evolve it without breaking old stuff. People have been solving this problem for YEARS though. That's why we have module systems, versioning, and even advanced ideas such as shipping an API mirror for version X that is actually interacting with an object of version Y, to let objects of that module cross the border between 2 modules with different version requirements for that module. Similarly, even if you do accept that rewriting/wrapping the core library is the only acceptable solution, how will you evolve THAT? If you don't solve this problem now, in 6 years we'll all be calling scala/fan/noop a fossil and moving on to the next shiny thing. I don't really feel like rewriting all my projects every decade just to stay with the times. I'm just not going to accept that. I hope the rest of you won't, either. We can fix this. Lastly, there's langtools. A mere trifle compared to the JVM and the library core. So, why not split it up? Right now maintainance/support of javac, java.exe (JVM), and runtime library (RT) is tightly bound: They all go out of support at the same time. Why is this? Decouple javac from the JVM and RT, completely. Give javac a name and don't let its version track the core libraries. You could then have the following situation: JVM/RT8 is released with a bunch of modern language primitives such as a closure type. DolphinJavac (what's now known as javac6) has been updated, bugfixed, and a few very minor backwards entirely compatible changes have been shipped with it. This v8 version of DolphinJavac may even require JVM/RT8 if you use all the features (just like javac5 needs JVM/RT5 if you use annotations, or iterable syntax, etc). If you've got a project under active maintainance, you switch to JVM/RT8 for it, and DolphinJavac8. A bit later, MahiMahiJavac is released, which contains loads of new features, including closures, traits, struct classes, pattern matching, lexically scoped monkey patching, and a bunch of other features. Old code (written for DolphinJavac) will generate a bunch of warnings and in some cases may even simply not work, but MahiMahiJavac is still very much javac - a few minor edits is all you need, and you should definitely go for it if you're working on an actively in- development project. As the early switchers to MahiMahi are clearly preferring updates to java-the-language, MahiMahi will continue to evolve fairly drastically for the JVM/RT9 timeframe, but at some point MahiMahi is in the same boat as dolphinjavac is in now, and it gets major-feature-freeze. A few months later, Seawolf is released. This process can be maintained essentially forever, and allows continues evolution of the language. On Sep 17, 6:34 pm, Joshua Marinacci <[email protected]> wrote: > (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 <[email protected]> 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 <[email protected]> wrote: > > >>> On Wed, Sep 16, 2009 at 12:59 PM, Reinier Zwitserloot > >>> <[email protected]>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 [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 -~----------~----~----~----~------~----~------~--~---
