7 ms·

The Next Big JVM Language

jhrobert 16y 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!
- m0th87 16y ago
  It's also about better IDE facilities. I mostly use Python now, but boy do I miss solid autocompletion and refactoring.
  - barrkel 16y ago
    Unfortunately, providing solid autocompletion for dynamic languages implies solving the halting problem.
    - mahmud 16y ago
      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.
      - barrkel 16y ago
        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().
        mahmud 16y ago
        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.
        barrkel 16y ago
        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.
    - pjscott 16y ago
      SLIME autocompletion for Lisp works beautifully, and that language is about as dynamic as they come. What's the problem here?
      - barrkel 16y ago
        I've addressed that in the other comments.
        pjscott 16y ago
        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.
thomas11 16y 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?
lemming 16y 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.
- dochtman 16y ago
  Yeah, I'm not sure what he wants with the static methods. I always pine for first-class functions when coding in Java...
- m0th87 16y ago
  Why are singletons worse than static methods?
  - Tichy 16y 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.
    - barrkel 16y ago
      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.
knowtheory 16y 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 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.
- pragmatic 16y 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.
deleted 16y ago
[deleted]
Rickasaurus 16y 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.
dochtman 16y ago
I still want my operator overloading back. Oh yeah, and something better than explicit getters and setters.
pragmatic 16y 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.
cageface 16y 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 16y 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.
  - cageface 16y 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 16y 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.
- cageface 16y 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 16y 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/ http://www.mirah.org/ But the alternative, of re-doing Java using the existing syntax with slightly different semantics, has serious dangers.
barnaby 16y 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.
- cageface 16y 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.
allertonm 16y 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 16y 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 16y ago
  Based on the statistics I've seen, yes.

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!

m0th87 16y ago
It's also about better IDE facilities. I mostly use Python now, but boy do I miss solid autocompletion and refactoring.
- barrkel 16y ago
  Unfortunately, providing solid autocompletion for dynamic languages implies solving the halting problem.
  - mahmud 16y ago
    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.
    - barrkel 16y ago
      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().
      - mahmud 16y ago
        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.
        barrkel 16y ago
        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.
  - pjscott 16y ago
    SLIME autocompletion for Lisp works beautifully, and that language is about as dynamic as they come. What's the problem here?
    - barrkel 16y ago
      I've addressed that in the other comments.
      - pjscott 16y ago
        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.

thomas11 16y 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?

lemming 16y 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.

dochtman 16y ago
Yeah, I'm not sure what he wants with the static methods. I always pine for first-class functions when coding in Java...
m0th87 16y ago
Why are singletons worse than static methods?
- Tichy 16y 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.
  - barrkel 16y ago
    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.

knowtheory 16y 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 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.

pragmatic 16y 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.

deleted 16y ago

[deleted]

Rickasaurus 16y 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.

dochtman 16y ago

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

pragmatic 16y 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.

cageface 16y 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 16y 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.
- cageface 16y 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 16y 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.

cageface 16y 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 16y 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/ http://www.mirah.org/ But the alternative, of re-doing Java using the existing syntax with slightly different semantics, has serious dangers.

barnaby 16y 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.

cageface 16y 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.

allertonm 16y 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 16y 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 16y ago
Based on the statistics I've seen, yes.