The Next Big JVM Language

http://www.jroller.com/scolebourne/entry/the_next_big_jvm_language1

27 39 16 years ago

jhrobert• 16 years ago

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.

Strong typing should be viewed as an optimization, either to optimize code's correctness or to optimize code's speed.

If you add CoffeeScript on top of that... whoa!

m0th872• 16 years ago

It's also about better IDE facilities. I mostly use Python now, but boy do I miss solid autocompletion and refactoring.

barrkel7• 16 years ago

Unfortunately, providing solid autocompletion for dynamic languages implies solving the halting problem.

thomas11• 16 years ago

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.

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?

lemming2• 16 years ago

"If you're still using or advocating checked exceptions, then I'm afraid your skill set is 5 to 10 years out of date."

Josh Bloch must be devastated.

"Code in static methods is inherently less reusable and accessible than code in objects."

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.

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.

dochtman2• 16 years ago

Yeah, I'm not sure what he wants with the static methods. I always pine for first-class functions when coding in Java...

m0th872• 16 years ago

Why are singletons worse than static methods?

Tichy3• 16 years ago

Because they have a state, I would suppose. My memory is actually foggy on why Singletons are bad. I guess they make it hard to make the app distributable, and they are generally error prone? Like how to make sure there really is only one of them.

crpatino• 16 years ago

Summary: singletons = global variables + static methods.

Details:

If you need some "utility function" whose output depends exclusively on its arguments, you will be better of with an static method. However, this is a no fly for O-O-purists.

The option is to create a (possibly stateless) singleton class and put your non static method there. You will have the overhead of acquire the reference to the method in run time instead of compile time (and the few bytes needed to store the class and the ONE object reference).

On the other hand, singletons can be used to hold global state and the methods to legally change that global state. For this reason, they can be easily abused in order to bypass separation of concern rules and dress them in OOP-speak.

barrkel7• 16 years ago

I think you haven't looked deeply at the range of module system designs, and are making a snap decision based on too little information.

With respect to static methods: change your perspective. What's a module? You can look at it as a collection of named, statically typed definitions. Your static methods live here.

But what if you want first-class modules? To compose systems at the module level? Then you need a value of a module type, a way of passing these modules around and parameterizing modules by their dependencies. But we already have a mechanism that looks just like this: objects! So, let our modules be top-level singleton objects, and we get the best of both worlds.

For more along these lines, look at E (capability orientation, with objects representing capabilities) and Newspeak, Gilad Bracha's latest project. Eliminating the ambient authority implied by top-level static namespaces is key behind these (dynamic) systems. But similar approaches are not necessarily restricted only to dynamic systems.

lemming2• 16 years ago

Oh, I fully admit that I'm not up to date with modern module language design, my answer was purely pragmatic - using static methods doesn't seem to have made my code less reusable in any way that's been significant to me, and I write large complex systems in Java. I think that making blanket statements like the OP (checked exceptions are bad, singletons are better than static methods) is a little absurd - Java is for better or worse a pragmatic language and using static methods instead of singleton objects makes my code shorter, clearer and easier to understand to mere mortals. That's a win in my book.

That said, I'm a closet programming language geek so I'll check out your references, thanks for the pointers.

allertonm2• 16 years ago

I'm mostly with you on static methods versus singletons but it's worth mentioning that a singleton object has the advantage of being able to implement an interface, but there is no such capability for separating interface and implementation for static methods.

I think static methods are OK for the same reason that not every object needs to be an implementation of an abstract interface, but you should be aware of the possibilities you are eliminating when you make that choice.

knowtheory• 16 years ago

> 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...

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".

It's almost comical how well this encapsulates Blub programming (http://c2.com/cgi/wiki?BlubParadox ). or more to the point, assumptions about blub programmers by the author, who clearly at least understands programming languages.

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.

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!).

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.

Change is hard, and it challenges lazy thinking in blog posts like this.

pragmatic2• 16 years ago

The question is, how much do you gain from this power or difference? That's the real challenge of language design, not what you put in, but what you keep out.

Rickasaurus• 16 years ago

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.

dochtman2• 16 years ago

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

pragmatic2• 16 years ago

From the conclusion of this article, porting C# to the JVM would be the best "new" Java language.

C# borrowed heavily at the beginning, seems like Java should return the favor.

cageface4• 16 years ago

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.

Dn_Ab• 16 years ago

Im learning Scala and the part that is currently tripping me up the most is the syntax around its OOP. Basically getting your head around all the ways that are not quite orthogonal to do the same thing is the big hurdle for me.

    def method(a:'type,...) {}
    def method(a:'type,...) = <expression>
    def method(a:'type,...) : type = {}

Undoubtedly due to my ignorance and I do see the usefulness in each version but why so many ways? And the sugar that makes constructors so nice are a headache with tags and java library interop. I kinda prefer the F# middle ground on how it does constructors like that.

And there are some other things to do with interop with Java - mainly varargs ive come up against tbh. I am sure I will have more trip ups as I learn. Otherwise I am very happy that a functional language like this exists on the JVM.

cageface4• 16 years ago

TBH I think Scala has gone a little too far in its syntactic flexibility, and the variety of syntaxes for declaring a method is a good example of this. The constructor shortcut can also be a bit of a pain on more complex examples.

On the whole though, I'm finding Scala coding a very pleasant experience. A solid FP language on the JVM is turning out to be a very powerful tool.

mark_l_watson• 16 years ago

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!)

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.

cageface4• 16 years ago

I've had similar experiences. Java is a clumsy language but it doesn't have to be absolutely terrible if you set aside some of the conventions.

10ren• 16 years ago

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 http://www.mirah.org/

But the alternative, of re-doing Java using the existing syntax with slightly different semantics, has serious dangers.

barnaby• 16 years ago

I work with groovy in my day job, and I have to say that it is the NBL on the JVM. It has:

* ease of adoption from existing Java developers because it's a superset of the java langauge

* the enterprise capability (which the author mistakenly dismissed it for) thanks to groovy++

* 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.

cageface4• 16 years ago

I wish you were wrong about this but I think you're probably right. I'd much rather see a more carefully designed and powerful language like Clojure or Scala succeed but the blubbiness of Groovy will probably win out.

allertonm2• 16 years ago

I've been wondering why Fan/Fantom has not had more traction, I rather like the pragmatism that seems to have guided its design.

Is it just not exciting enough?

javanix• 16 years ago

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.

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.

chromatic• 16 years ago

Based on the statistics I've seen, yes.

The Next Big JVM Language

Related Stories