I never said Java should or would stop evolving. I'm explaining why Java must, of necessity, evolve slower than a brand new language.
With regards to lang interop and closures in JDK 7: here's my thoughts. Think of JDK 7 as our Snow Leopard. It's not about sexy new features. It's about fixing long standing issues in the platform. The two most important features are modules and invokeDynamic. JDK 7 is about getting Java ready for the next 20 years. So that it *can* evolve. This is much needed work and I think reducing the scope of JDK 7 to just those (no closures, no swing app framework), is vital to the long term health of the platform. - Josh On Sep 17, 2009, at 5:46 PM, Reinier Zwitserloot wrote: > > 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 <jos...@marinacci.org> 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 <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 -~----------~----~----~----~------~----~------~--~---
