The Next Big JVM Language

&#62; 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...<p>That seems ironic given the conclusion of the post. The reasons for rejection of Clojure and Scala are respectively "Clojure is too different fom Java", and "Scala is too powerful".<p>It's almost comical how well this encapsulates Blub programming (<a href="http://c2.com/cgi/wiki?BlubParadox" rel="nofollow">http://c2.com/cgi/wiki?BlubParadox</a> ). or more to the point, assumptions about blub programmers by the author, who clearly at least understands programming languages.<p>The thing about this is, I don't see why we have to replace Java. The power of the JVM is that there need not be One True Language To Rule Them All.<p>Let people program in Clojure or Scala or JavaScript or Ruby. Design sensible interfaces for data interchange, and let people get on with their lives (and promote Polyglotism!).<p>Searching for the Next Big JVM Language is like searching for the next Facebook. Sure there are going to be new popular entrants, but the ecosystem is such that there will never be another Java, just the same way there won't be another Facebook.<p>Change is hard, and it challenges lazy thinking in blog posts like this.

"If you're still using or advocating checked exceptions, then I'm afraid your skill set is 5 to 10 years out of date."<p>Josh Bloch must be devastated.<p>"Code in static methods is inherently less reusable and accessible than code in objects."<p>I'm really not sure this is true. Since I've started programming in functional languages more I find myself using static methods more and more - my code seems to be perfectly reusable. I still use objects where they make sense, of course, but using singleton objects instead of static methods is insane.<p>The idea of a Java 3 (with corresponding new JVM) is an interesting one, though. It really shouldn't be that hard to create an automatic conversion tool since the semantics are formally specified. However I suspect that unlike what most Java programmers would like to think, most of the decisions around the Java language really aren't made with programmer comfort in mind - things like backwards compatibility and tool support have historically been much more important.

I have been using Java since the early beta releases and I have written a few books on Java. That said, I don't use the language very much anymore, preferring Clojure and JRuby wrappers for useful Java libraries, and sometimes Scala (really a nice language!)<p>I know it is bad form, but when I do still use Java for my own work, I have started making it look a bit like Ruby by using public instance variables (no getters/setters). Also, by not using checked exceptions and heavy use of generics I can keep code fairly concise.

I would suggest the next big JVM Language should be a blend of JavaScript and Java where one would provide optimization hints to a javascript program using element of java syntax.<p>Strong typing should be viewed as an optimization, either to optimize code's correctness or to optimize code's speed.<p>If you add CoffeeScript on top of that... whoa!

The author focuses on the removal of features from Java, like generics and method overloading (!). His polemics about complex features ("Scala [...] quickly bites your head off") are unnecessary.<p>But from a hacker's point of view, Java is not expressive enough. Do we need to accept a dumber mainstream language for "the masses", or can we advance the state of the art by moving most developers to more expressive languages?

From the conclusion of this article, porting C# to the JVM would be the best "new" Java language.<p>C# borrowed heavily at the beginning, seems like Java should return the favor.

I work with groovy in my day job, and I have to say that it <i>is</i> the NBL on the JVM. It has:<p>* ease of adoption from existing Java developers because it's a superset of the java langauge<p>* the enterprise capability (which the author mistakenly dismissed it for) thanks to groovy++<p>* finally, if you were to change Java the way the author suggested for Java 8 and 9, then it would end up looking like Groovy anyway. So DRY and just adopt Groovy as the NBL and leave Java to be backwards compatible.

The people that dimiss Scala as too complicated almost never seem to have actually tried it. Scala can look scary on paper but it's really not hard at all once you start real coding in it.

I still want my operator overloading back. Oh yeah, and something better than explicit getters and setters.

Mirah is arguably what he suggests: an attempt to redo java - though with Ruby-like syntax, so it wouldn't be particularly adoptable by the hoards of Java developers <a href="http://www.mirah.org/" rel="nofollow">http://www.mirah.org/</a><p>But the alternative, of re-doing Java using the existing syntax with slightly different semantics, has serious dangers.

This is one of those rare occasions when I wish I could actively vote down an article. Seems more like a "get off my lawn" post than anything. Also, his reasons for disliking Scala are completely arbitrary.

<i>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.</i><p>As an aside, are Perl and PHP in wide enough use to really support that 15% figure? Just curious - if I were making that list based on my own perceptions and experience I would leave those two and possibly COBOL off of it.

I've been wondering why Fan/Fantom has not had more traction, I rather like the pragmatism that seems to have guided its design.<p>Is it just not exciting enough?