The Next Big JVM Language | Hacker News Reader

The Next Big JVM Language

jroller.com

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

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.

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

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

Why are singletons worse than static methods?

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.

Static fields are also state. Singletons have a bad rep in C++-land and similar because they have initialization problems - static initialization is a PITA with C-oriented linkers.

A lot of the problem here is branding. Schemes that are isomorphic with one another, and called singletons in one language and modules in another, are respectively reviled and lauded, sometimes by the same people.

The question was about static methods, though.

It's my position that the question "why are singletons worse than static methods" is ill-formed and implies a dichotomy where there need not be one. Static methods are already instance methods on an implied singleton, whose state consists of static state; except this singleton doesn't have an identity and isn't a value that you can pass around, and so isn't composable, isn't first-class.

Sure, in that sense it is the same. I was thinking about methods without side effects. Then it wouldn't matter if they exist in several instances, I suppose.

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.

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.

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.

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.

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.

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.

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!

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

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

How so? you just need reflection. Slime does it for Common Lisp and it doesn't break a sweat, that is, without using any advanced MOP stuff.

Reflection implies that you're running the code at code editing time, otherwise there's nothing to reflect over. That, in turn, opens up a huge can of worms for a large class of applications which aren't easily editable in what effectively is a debug session.

Just to be clear, this is what I mean when I talk about autocompletion (cursor is |):

    def foo(bar):
        bar.|

In order to complete on bar, you need to know the symbols available on the potential runtime values of bar. Everything can be in a system image, and you still don't know what gets through to foo() unless you either symbolically or actually evaluate the code and have a semantic breakpoint at the start of foo().

Reflection doesn't mean "you're running the code at editing time". I hope we're not confusing Java reflection with Eclipse's aggressive compilation of things as you type.

As per your specific example, I think the reason SLIME works is because Common Lisp uses generic functions, instead of class methods. The calls are not Object.Method() rather Method(Object:Class) so Metho| always resolves.

However, I will grant you this: automatic class loading will easily trip up SLIME and similar tools.

Hmmm, I am gonna need to think about this further.

I have no idea what Eclipse does as you type; I don't normally use Eclipse. I am, however, employed to maintain a static language compiler which is used by its IDE for code completion (Delphi in RAD Studio). I also implemented the runtime reflection object model (Rtti unit) used in the latest versions of Delphi.

By reflection, I'm talking about interrogating runtime objects to see what's available on them. They need to be runtime objects because of monkeypatching and similar techniques. Because they're runtime objects, in some sense the code needs to be run in order to interrogate the objects. That execution may be symbolic, but that symbolic evaluation hits the halting problem, because it's normally a Turing-equivalent machine which determines how the objects will get constructed.

SLIME autocompletion for Lisp works beautifully, and that language is about as dynamic as they come. What's the problem here?

I've addressed that in the other comments.

Oops; your reply happened between the time I loaded the page and the time I hit the reply button. I think it would be cool if Reddit-style comment systems could show new comments in realtime, Wave-style. The number one complaint about wave is that "it's cool, but I don't know what I would use it for". People already know what to use sites like HN for.

I'm not sure how usable it would be to have comments suddenly appearing -- it might get overwhelming if there are over 1000 comments, as on some Reddit articles -- but I think it could be pleasant on a smaller site like HN.

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?

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.

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.

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.

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.

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.

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.

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

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.

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.

Based on the statistics I've seen, yes.

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?

Reply on news.ycombinator.com