Tuesday, 21 September 2010

The Next Big JVM Language

At JavaOne on Monday I spoke on the topic of "The Next Big JVM Language". My conclusion wasn't what I expected it to be when I started researching the topic. Read on to find my conclusion...

The Next Big JVM Language

To discuss this topic, we first have to define what is a "Big Language". Specifically, I defined it as being a key or dominant language, with wide usage and job market, established and with supporting ecosystem and community. Another possible definition that 15% of the developers in the world are using that language at a point in time. Based on these, I listed C, C++, Java, C#, COBOL, VB, Perl, PHP and Javascript as Big Languages. Depending on your cutoff point, you could argue for others, but that seems like a good starting set.

I then looked at what Java got right and wrong. Certainly Java got a lot right - its used by 10 million developers. But it got a lot wrong too...

Well, thats unfair! Java is 15 years old. We are applying a historical judgement to Java, and many of the choices made in Java 1.0 were appropriate then, but not now. Its much better to ask "what we have learnt from Java".

Learning from Java

I looked at some key points in the Java language that we have learnt over 15 years.

1) Checked exceptions. Spring rejects them. Hibernate rejects them. Java EE rejects them. They are a failed experiment (good in theory, bad in practice). Now, many reading this blog still hold checked exceptions dear to your hearts. But I'm afraid its finally time to say "wake up and smell the coffee". Checked exceptions have been rejected by all the key industry API writers and leaders at this point. If you're still using or advocating checked exceptions, then I'm afraid your skill set is 5 to 10 years out of date. Period. (I know that may sound harsh, but to those in that camp, you seriously need to open your mind to what modern API design is about.)

2) Primitives and Arrays. Both these features expose low level details from bytecode. They break the "everything is an object" model. The lack of generics over primitives is a classic example of this. The correct solution is a language where the source code does not have exposed primitives or arrays, and the compiler (or perhaps the JVM) works out if it can optimise it for you.

3) Everything is a monitor. In Java and the JVM, every object is a monitor, meaning that you can synchronize on any object. This is incredibly wasteful at the JVM level. Senior JVM guys have indicated large percentage improvements in JVM space and performance if we removed the requirement that every object can be synchronized on. (Instead, you would have specific classes like Java 5 Lock)

4) Static. Code in static methods is inherently less reusable and accessible than code in objects. This, together with constructors, often results in a need to have explicit factory interfaces, making APIs more complex. A better solution is singleton objects, which can be used most of the time just like a static, but can be passed as an object when required.

5) Method overloading. One of the most constraining parts of the Java language specification is method resolution, where the compiler has to work out what method you intended to call. Resolution touches superclasses, interfaces, varargs, generics, boxing and primitives. It is a very complex algorithm, that is difficult to extend. Having no method overloading, except by default parameters, would be a huge win.

6) Generics. Java generics is complex, especially around the ? extends and ? super variance clauses. Its too easy to get these wrong. The lesson from Java should be that use-site variance hasn't worked out well.

I could have chosen others, but these are a selection of items where we have learnt from Java.

What might NBJL contain?

Looking forward, I argued that human factors are key in the adoption of a next mass-appeal language. I put forward a simple test for the ability of any new language to be adopted:

1) Take a piece of code in the new language. A piece of reasonable complexity that a typical developer would be expected to deal with day-to-day.

2) Give the code to a mid-level developer. Someone who is not interested in blogging, tweeting or new languages in general.

3) Can they make a reasonable guess as to what the code in the new language does? Without any help or training.

Now this is a fairly harsh definition of how far NBJL can evolve, but it is I believe quite a practical one. The truth is that we need to be able to transition to the new language without massive training programmes.

In terms of features, I covered a long list of features and issues that a new language should address.

  • C-like syntax (familiar and good-enough)
  • Static typing (dynamic is too loose and ineffective for this type of language)
  • OOP with functional elements (pure functional too hard for mainstream)
  • Easy access reflection (to escape the static typing restrictions)
  • Properties (because getters and setters are crazy)
  • Closures (capturing looping design patterns)
  • Null-handling (preferably a means to declare whether each variable can or cannot hold null)
  • Concurrency story (something better than raw threads and shared mutable state)
  • Modules (need to be thinking in terms of larger units)
  • Tools (need a language to be designed to help tool writers)
  • Extensibility (allowing some additions without going back to the language designer)

There are many other concepts that could be discussed - language design is fairly obviously a design artifact, and so different views and opinions are likely.

So, what language?

1) Clojure is a functional programming language, using syntax from the LISP family. It has some great ideas on handling state, which change completely the approach Java developers are used. to. However, it is a million miles away from Java in syntax and function approach.
NBJL isn't Clojure.

2) Groovy is a dynamic language with optional typing. It is heavily based on Java, using the syntax and structures directly in many cases. This makes it very quick and easy to pick up, and use. Its strengths are in scripting and web pages, where the dynamic and meta-programming elements shine. The dynamic nature makes it a poor choice for large bodies of core entterprise server logic.
NBJL isn't Groovy.

3) Scala is a OO/functional language, using C-like syntax. On deeper examination, it can be seen that the functional side is more significant. In particular, the culture of the language pushes users to the more pure functional solutions. Scala is statically typed, to the extent that the generics of Scala is apparently Turing complete. But, does writing a programming language in the generics of another programming language really make sense?!! To cover all the elements of Scala complexity really needs to write a separate blog post. Suffice to say that Scala simply gives developers way too much rope to be able to hang themselves by. While it may at first glance appear to offer the better than Java features that are being searched for, it quickly bites your head off once you go beyond the basics - its simply a language too complex for the mainstream.
NBJL isn't Scala.

4) Fantom is an OO language with functional elements, using C-like syntax. It has very simple and neat solutions to topics as diverse as nullable types, immutability and modules. It has a static type system with a relaxed approach. Geerics are only supported on Lists, Maps and Functions, and developers cannot add their own. To compenstate, the language sutomatically adds a cast wherever a developer would normally have needed to add one. While Fantom contains almost a complete sweep of what a sensible mainstream language should contain, it hasn't received that much attention. One point of concern is whether the type system is strong enough to attract lots of developers.
Fantom is closest to NBJL of these languages, but seems unlikely to succeed as the more relaxed type system seems to scare people off.

At a personal level, each of these four languages will teach you something new if you learn it. Clojure and Scala in particular will teach you about functional programming if you've never been exposed to it. However, NBJL is about picking a language suitable for use by everyone for all tasks, in a team and enterprise environment. While each of these four has a niche, none of them are currently placed to jump up and replace Java.

An alternate approach

There are 10 million Java developers. Any improvement that affects all 10 million has a big benefit for the cost. But none of the current languages is capable of being that next language.

Maybe we should reconsider Java?

What if we created a backwards incompatible version of Java (the language)?
Where we fixed the things we know are broken? (exposed primitives, arrays, checked exceptions, ...
Where the changes were not too massive to create the need for formal training courses?
Where a tool converts old code to new code (and vice versa) with 100% accuracy? (providing the essential backwards compatibility)
Where features like closures and properties could be added with the current compromises?
Where you only compile modules, and never single class files?
Where the compiler/module-linker can determine that two versions of a module use the same bytecode for the operations you actually call, therefore they are actually fully compatible? (and other similar module version transformations)

What if the community asked Oracle to do this instead of JDK 8? (accepting a delay to 2013) Or as JDK 9?

Is it time to learn the lessons of Java? And apply those lessons to Java itself?

Summary

Any talk on languages is controversial, as each language has a specific world view and fans. I rejected Clojure, Groovy and Scala as NBJL even though each is a good language in its own way. I concluded that Fantom is closest to the statically typed mainstream language that is needed, yet its simple type system and some of its APIs are counting against it.

As a result, my conclusion is that the language best placed to be the Next Big JVM Language is Java itself - just a backwards incompatible version. And I suggested that maybe we should accept a 2013 release date (instead of 2012) for JDK 8 as a backwards incompatible version.

Feedback expected! Please use #bijava to talk about backwards incompatible Java on twitter.
PS. I'll get comments invalidly marked as spam out as soon as I can!

36 comments:

  1. To imagine all the resources spent on JavaFX Script and what that could've done for a revitalized, backwards incompatible version of Java.

    However, Sun has been religious proponents of backwards compatibility... preferring to dig themselves deeper and deeper down in the hole.

    Therefore, is it really realistic to expect JDK8 to be more than the typical patchy evolutionary step? I hope so, but remain skeptical. The trend towards Scala suggests we'll just see a fragmentation between mainstream and the elite.

    ReplyDelete
  2. I agree with you in 100%. Java 7/8 will not be a huge step in making Java better language or more popular. Sure, there will be some nice features, but honestly: it's not enough. Your proposition about Java 8/9 is exactly what Java world needs. Maybe that Java 8/9 should be called Java++ and "old java" should be still maintaned for next few years in order to provide support for older applications. I hope, that Oracle will consider this scenario.

    ReplyDelete
  3. I'm very much in favor of a backwards incompatible Java version in the future. IMHO, fixing the mistakes would better than a whole new language. However, I believe first the language needs to be separated from the class library and a proper modularization is required.

    Ideally one could mix a Java Language Module of version X.Y (consists only of the language itself and java.lang.*) with some Java Library Modules Z.W (eg. java.io.* of version z.w).

    And of course the runtime/byte code layer should be independent as well.

    With this we never had to wait for a while new JDK but could run a separate upgrade of
    - the JVM (e.g. with a newer/better GC)
    - the language (e.g. a new syntax)
    - an individual library module (e.g. like the nio2 enhancements)

    ReplyDelete
  4. I think there is no room for a kind of NBL you propose. Java does it job as an enterprise programming languate very well.
    And it does not matter with whatever NBL our industry comes up, the NBL will look flat compared with the power and elegance that Scala offers now.

    ReplyDelete
  5. Sounds good, though lots of complexity in there though. In particular, what are the lessons around the extensive built-in libraries?

    ReplyDelete
  6. On checked exceptions:

    - Your disqualification of devs who like it as outdated/incompetent is just rhetorics, and pretty gross IMHO. Learn to respect different opinions. There are definitely some "key industry API writers and leaders" that like checked exceptions; and the few important libs/fwks that reject checked exceptions are... well, the exception, not the rule, even among brand-new designs.

    - Spring is very far from a unanimity. Lots of people hate and reject it (yes I'm in that group).

    - Java EE 5+ does NOT reject checked exceptions. It does reject RemoteException (that particular exception was a design mistake); some others are also avoided as side effect of more automation (e.g. dependency injection) but that's about it. Checked exceptions continue to be supported pervasively.

    - The Java 7 language will make checked exceptions massively more convenient (less bloated) with ARM, final rethrow and multi-catch. There's also some continued API fixing, like ReflectiveOperationException. This will make null and void the biggest complain (that I also have) against checked exceptions.

    ReplyDelete
  7. NBJL also needs better reflective and meta-programming facilities....

    ...should be possible to refer to fields and methods without using Strings.

    ...should be able to discover all classes that are subtypes of a given class or that implement a given interface.

    ...should be possible to declare 'metadata' in code modules, that is, instances of classes instead of just classes. There should be a way to discover/query this data.

    ReplyDelete
  8. Where does this fear of complexity come from? Scala never bit anyone's head off. If you find certain features too complex, don't use them, and mandate that in your department's coding standards. I also consider a Java developer who doesn't knows basic generics worse than mid-level.

    If the next big language is less expressive than Java, it will make it only harder to write the advanced and difficult stuff in it. And that's where it matters. The world of development will split even more in the advanced camp, and the boring-GUIs-and-web-forms camp.

    Can't we avoid that?

    ReplyDelete
  9. I agree that the most likely way to create the next big language is to start with an existing big language. Java, C++, and C# all fit this model.

    Some of the complexity in Scala is present to aid interfacing with Java. A better Scala might be created by removing a few features. I agree though that, as it stands, it is too complex for general use.

    Automatic translation to a Java derivative that addressed the features you mention might be quite challenging, especially if the result was required to have similar performance.

    ReplyDelete
  10. Some very good points. What I don't understand is why Oracle needs to drive this effort. There's nothing stopping you or some company from doing this. The community cries for a truly open language + spec for Java; why not just get together, start a standards body and do it? I don't really know how, nor do I care that much, but plenty of others who complain about Java and the JCP not being open enough do. So, Apache, IBM, Google, others... show us how it's done!

    ReplyDelete
  11. Fix Java and you end up with Scala. It's as simple as that.

    The thing you imagine has already been done. Go through "Java Puzzlers" one-by-one and check if these bugs/design mistakes still exist in Scala (hint: most of them are fixed, while some are maintained to be more compatible with Scala).

    1) Checked exceptions.
    Fixed.

    2) Primitives and Arrays.
    Fixed.

    3) Everything is a monitor.
    Every reference type in Scala inherits from java.lang.Object for compatibility reasons.
    Java has to fix it.

    4) Static.
    Fixed, but creates static forwarders for java compatibility.

    5) Method overloading.
    The JVM has this hard-coded. InvokeDynamic might allow languages to do method resolution on their own. Java compatibility.

    6) Generics.
    Fixed. Won't get better without full reification.
    http://lamp.epfl.ch/~emir/bqbase/2006/10/16/erasure.html
    The problem is that there is no VM currently which can handle all necessary aspects of it. The JVM doesn't even know Generics yet and the .NET VM can hardly handle co-/contravariance.

    As you see, most complexity stems from the fact that Scala tries to be as Java-friendly as possible. Some things which would have been easily possible (like classes only different in their arities, like in C#) haven't been done, because the necessary name mangling wouldn't have looked good from java.

    Let's go on...

    C-like syntax: Yes!

    Static typing: Absolutely.

    OOP with functional elements: That's Scala's definition.

    Easy access reflection: Scala devs are currently writing their own, because Java's isn't good enough.

    Properties: Yes.

    Closures: Yes.

    Null-handling: Yes, via Option, which is more correct and general than the "Elvis" operator.
    Nulls still supported due to Java compatibility.

    Concurrency story: A whole truckload of them for every purpose. Look at Akka as an exmaple or the implementation of the new parallel collections.

    Modules: Yes.

    Tools: The Scala compiler has a whole API which IDEs can use instead of implementing things themselves. Work is being done to improve all three major IDEs: IntelliJ, Netbeans and Eclipse.
    SBT is currently the best dependency management and build system available.

    Extensibility: Yes, Implicits.


    If any language will be able to unseat Java (which I don't expect) it will be Scala.

    Actually, Scala is far easier than Java. Seeing all these mediocre applications and libraries in Java, it is clear that Java is too complex for the average programmer.

    ReplyDelete
  12. You should check out Groovy++, the statically typed extension to Groovy. It has all the advantages that you mentioned for Groovy, but eliminates the one disqualifier that you listed. That makes it a candidate for the Java++ title.

    ReplyDelete
  13. "[...] while some are maintained to be more compatible with Scala)."

    Should of course read Java instead of Scala.

    ReplyDelete
  14. Sounds in large part it isn't the language per se that's the problem, it's unskilled use thereof - to wit, a whiny list of wishing the language would prevent you from shooting yourself in the foot. It's not a list of what you wish the language could do, it's a list of what you wish you couldn't.

    Solution: don't shoot yourself in the foot. Stop pointing guns at your own appendages.

    In the spirit of Godel, all languages will have some aspect which can be construed as "broken". Let's focus on enhancing and extending the language, not stifling it.

    ReplyDelete
  15. We already have NBJL:
    +1 for Fantom

    Scala is great too, but I like Fantom more.

    The argument "the more relaxed type system seems to scare people off" seems weak.

    See a Fantom success story: http://ksat.me/kloudo-a-fantom-success-story/

    ReplyDelete
  16. Reified generics. Seriously. Type erasure driven generics were adopted for backward compat reasons.

    ReplyDelete
  17. 1) Checked exceptions.

    Entirely indifferent here. Yes, it creates boilerplate, but the compiler-enforced throws statement can help you understand a method's behavior.

    2) Primitives and Arrays.

    Should be fixed. Love to see them go away.

    3) Everything is a monitor.

    Hadn't ever really considered it. If it's a cost, then it may be worth a fix. Either locks or a marker interface could be used for the same job.

    4) Static.

    Should be fixed.

    5) Method overloading.

    I feel like I'd have to play around with any alternatives before deciding.

    6) Generics.

    Improved generics would be nice, though again more details would be needed on the alternative.

    --

    My major headache in using Java lately has been Serializable. Suddenly finding out that someone broke the contract of a Serializable parent class that your implementation can't touch is awful.

    Perhaps the solution would be to default with everything being Serializable unless they explicitly override the interface to throw Unsupported Operation? That would put the interface to work as well, leaving it as more than a mere marker.

    ReplyDelete
  18. There want be a "NEXT BIG LANGUAGE". Instead of searching this the should make interop between the languages easieer and make the plattform better so everybody can use what they want. Even Java if the are crazy.

    ReplyDelete
  19. Before dismissing Scala as "too complex" (especially relative to Java!) you might want to take a look at . It might prove enlightening. :-)

    ReplyDelete
  20. The idea that you have to be Scala to fix Java is utter nonsense. Scala improves some APIs...that could be improved in Java. Scala adds some superficial language features...that could be added to Java (or NBJL) without the library requirements Scala imposes. Scala goes so far beyond fixing Java that it's almost nonsensical...perhaps it's a great and powerful thing to be able to reason about higher kinds in a language, but I just need to write a goddamned web UI. If I can write it in Ruby code and have it be more understandable than a higher-kinded, massively-abstracted Scala program, there's something seriously wrong with the Scala approach.

    What's needed here is another incremental step beyond today's Java. Add the bits and pieces to Java that are missing (or build a new language that's Java's reasonable parts with those missing bits). Improve the APIs that Java builds upon, either through a lightweight library or by fixing them in the JDK itself. And ideally, don't impose a giant runtime dependency just because you choose to use those superficial language features; if you can't express it in JVM types and JVM bytecodes, you're pushing too hard.

    ReplyDelete
  21. "If I can write it in Ruby code and have it be more understandable than a higher-kinded, massively-abstracted Scala program, there's something seriously wrong with the Scala approach."

    I do not understand...
    Than there is something seriously wrong with your approach to write the program in Scala?
    That's true.

    Otherwise, perhaps you could write it in Scala code that is more readable than a higher-kinded, massively abstracted Ruby program.
    Then again something would be wrong with the Ruby approach?

    It is currently very annoying that people mistake what one _can_ do in a language with what one _must_ do in a language to achieve certain results.

    +1 for Thomas Kappler here.

    Beside: The problem also seems to be the idea that a NBL could address the currently emerging problems of web-development, concurrency, distributed computing, more and more evolving business complexity a.s.o. and at the same time be easy like Basic and without any difference to language X one already knows.

    The world is heavily changing but please let me stay the same and feel comfortable.

    Guys, that doesn't work! When the land is flooded we better learn nautics and build ships instead of improving the bicycle.

    ReplyDelete
  22. I find Scala to be a lot easier to use than Java. Especially 2.8. Things are just more orthogonal in Scala, especially around collections. Everything works the same whether it's a list, array, ArrayList, etc.

    It takes a month or two to adjust to using filters and maps but it reduces so much code down to a really simple, easy-to-read line of code.

    I love the type inference too.

    I think Snoracle should just focus on keeping the JVM top-notch and leave the language innovation to others. The JVM is the real crown jewel.

    ReplyDelete
  23. Agree with steve "If any language will be able to unseat Java (which I don't expect) it will be Scala."

    Scala brings in features that are well beyond what Java can offer, bridging the gap between functional programming but not tying you into the latter. If anything, Java 8 has lots to learn from Scala.

    While we try to invent NBJL, Scala offers you right here, right now, the tools you need for building mission critical enterprise software.

    Although a language must strive for simplicity, it has to be ambitious enough to offer tools for developers to come up with innovative ideas.
    In this sense, I see both Scala's and Groovy DSLs delivering the most benefits, specially the former, since it supports them natively with parser combinators.

    ReplyDelete
  24. To those who say "Scala is perfect because it has ALL the features" ... you don't get the point.

    More features is not always better ... and I'll argue one of the fact that made Java popular in the first place, was it's lack of features ... which means easy to learn and Maintain.

    A lot of language geeks/researcher don't maintain huge pile of corporate code daily, which is what 9 out of the 10 millions java devs do daily.

    Now if I'm gonna maintain some code, especially not mine I would much rather have it not written in Perl of Scala, where people can make up their own stuff.

    I like Groovy and Fantom the most myself, Groovy as the easiest migration path from java and is already used by quite a lot of people (a little), although because it's mostly dynamic I feel it's best use for scripting.

    For "core" code I prefer Fantom(mostly static), which I feel is a lot like Java would be if it was rewritten from scratch right now, without all the earlier mistakes, and "new feature while staying backward compatible" hacks, and API's that got super cluttered overtime - I think Fantom just lacks publicity.

    ReplyDelete
  25. Have you never heard of groovy++ or mirah?

    ReplyDelete
  26. Stephen Colebourne23 September 2010 21:12

    Thanks all for the great discussion. A few specific comments:

    - Why not Scala/Why is Scala too complex. I will blog soon on this.

    - Groovy++/Mirah/... I chose 4 languages which represent a category of solution to the problem, and couldn't talk about everything in an hour long talk or blog.

    ReplyDelete
  27. Scala as NBL??? Come on guys...

    Maybe "Scala-the-language" has nifty concepts, some of them worth to be incorporated into a NBL, but "Scala-the-platform" in it's current state is more tightly coupled to good old Java than a Romeo and Juliet ever were. It does not even define a string, date or I/O stream on it's own...

    ReplyDelete
  28. Very interesting discussion. A sweet spot of Java has been it's "blue collar" nature. A working programmer could understand all aspects of the language. Contrast this with the byzantine complexity of C++ whose users at some point simply must declare their faith in the library designers and hope for the best.

    At least, Java 1.0 had that ideal "blue collar" nature. I have met plenty of programmers who didn't understand inner classes, serialization, reflection, or, of course, generics. Ok, make that Java 1.0 except for monitors--lots of working programmers don't understand those either. In fact, I'd add to your feature list for the NBJL "blue collar concurrency".

    Creating a "blue collar" language isn't something that happens every day.

    When done by "blue collar" people who have no knowledge of programming language theory, the result is often problematic. Look at PHP--I won't have to elaborate... Or Groovy, many of whose most important aspects (particularly in the MOP) are under-specified and constantly shifting.

    The "white collar" people give us languages that dazzle us with their brilliance and innovation. After all, that's what a researcher is rewarded for.

    As white collar languages go, Scala is better than most. Much attention is paid to compatibility with the JVM, the Java libraries, and the tools infrastructure. This isn't the "just shut up and use Emacs" crowd.

    Still, in order to be a happy user of Scala, you will need to put your trust in those people who forever go on writing incomprehensible blogs about category theory. For example, I have no desire to actually understand "higher kinded types", but as a user, I happily take the result: By calling someCollection.someMethod, I get back another collection OF THE SAME TYPE that I started with.

    It is entirely possible that the programmers who today have an imperfect understanding of Java 5, C++, or C#, and who muddle through anyway, will be just fine with Scala. As are, of course, the folks who write those incomprehensible blogs.

    A problem with Scala is that it doesn't appeal so much to those who would like to be able to grok the whole language, without wanting to learn more about programming languages than they already know. In this, Java was pretty unique. (It helped that the things that you needed to put your faith in--GC and the JIT--were pretty well hidden.)

    ReplyDelete
  29. > What if the community asked Oracle

    Hilarious

    ReplyDelete
  30. @David: That's called "Java compatibility". I could live without it, but then much more people like you would be complaining ... especially about how "bloated" the runtime is and how it "duplicates" existing functionality.

    Strings: The Java implementation is tightly coupled to the underlying architecture in more ways than you want to know ... while the String handling isn't quite Unicode-aware e. g. "charAt" it is so heavily optimized and tuned, that it doesn't make sense to build a different one. Improvements like verbatim Strings and some additional methods make java.lang.String bearable though.

    Date: Currently people are waiting if JSR-310 ever gets into the JDK. Unless this isn't clear, it doesn't make sense to duplicate things.

    I/O: Java's libraries heavily rely on VM intrinsics and don't even work properly until NIO2 gets into JDK. Doesn't make sense to duplicate non-working functionality, if the VM doesn't support doing things right yet.

    In the end, there is a reason why Scala made many choices which made the language a bit more complex: Java compatibility and the ability to reuse existing Java libraries. Why duplicate things without good reasons?

    ReplyDelete
  31. Don't agree , its not worth sacrificing backward compatibility just for Checked Exceptions and other things.

    No one can imagine java without backward compatibility and run anywhere architecture.

    ReplyDelete
  32. I think the times where there used to be a single big language are gone. Better get used to it.

    ReplyDelete
  33. It is no secret Java as a platform offers numerous options for developers. IMO, JVM languages are smart and clever as they don't heel to the JCP as we all know how hard is to get something into Java that would take years to offer. JVM languages are healthily fueling innovation in the Java ecosystem for good.

    Java is certainly going to be here for sometime for those who are afraid of a potential replacement. Just, choose your own weapon, a language that meets your needs, does not need to satisfy everyone on the planet.

    ReplyDelete
  34. YAY! Speculation and fanboy-ism at its best!

    There will never be "one language to rule them all", regardless of architecture or platform. The world is moving towards hybrid environments, especially now that one single application relies on so much infrastructure. Java, Python, C/C++, JavaScript, Perl, Lisp, Delphi, and on and on.

    Being a system administrator for as many years as I have, the trend is heading that direction. Hybrid environments.

    ReplyDelete
  35. Funny thing that C# covers all those points (except for monitors, which they now admit was a design mistake, and static methods which can be abused but still have their uses).

    ReplyDelete
  36. +1
    Backward compatibility is highly desirable--but every 10 years, it's time to step back, reappraise, and start anew. Support the old version with fixes, but stop extending it, already! I attempted to make that argument at Sun many times--in vain, alas. But I fully agree with your assessment. The next big language could easily be a stripped-down and simplified Java!

    That said, I also agree that modules connected by REST APIs is the most flexible architecture. Once APIs are defined, different modules can use any language or libraries they need.

    ReplyDelete