Summary:
At the JavaOne 2010 conference in San Francisco, Stephen Colebourne, member of technical staff at OpenGamma and project lead of the Joda Time open source API, gave a talk entitled "The Next Big JVM Language." In this interview, he reveals what he thinks the next big language should be.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: September 24, 2011 10:36 AM by
|
At the JavaOne 2010 conference in San Francisco, Stephen Colebourne, member of technical staff at OpenGamma and project lead of the Joda Time open source API, gave a talk entitled "The Next Big JVM Language." In this short interview, he reveals what he thinks the next big language could be. http://www.artima.com/lejava/articles/javaone_2010_the_next_big_jvm_lang_stephen_colebourne.htmlWhat do you think the next big JVM language will be, and what do you think of Stephen's idea?
|
|
|
I couldn't disagree more about Scala being too complicated. If Java has taught us anything its that people will find a way to hang themselves whilst shooting themselves in the foot no matter how simple the language.
My personal experience over the last couple of years with scala is that it results in much simpler, easier to read and easier to maintain code.
You can use very sophisticated techniques (eg scalaz) but the average programmer needn't go that far to greatly simplify their work.
We really shouldn't be afraid of using sophisticated languages and tools.
|
|
|
> But maybe rather than us going out there and saying to > Oracle, "Let's add closures to the language; let's add > properties to the language," what if we made a backwardly >incompatible version of Java?
Who is "we?" If you mean Oracle, it won't happen. Not in their interests. If you mean the Java open source community, then ask Google how it feels to mutate the JVM.
This sounds like an appealing idea: Java 2010. I just don't see how it can happen practically or legally.
FWIW, in some alternate reality where this proposal could happen, I doubt the resulting language would be significantly less complex than Scala.
These are very interesting times.
|
|
|
Scala advocates don't like to hear that Scala is too complicated, but it's a fact that this perception is widespread. For example, on Artima itself just a few days ago (second comment): http://www.artima.com/forums/flat.jsp?forum=226&thread=305560Or this thread on reddit: http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmu
|
|
|
> Scala advocates don't like to hear that Scala is too > complicated, but it's a fact that this perception is > widespread.
And depending on the programmer this can be true or not.
With the greater flexibility of the Scala syntax, it is possible to build solutions that look significantly more complex and harder to understand.
Equally, a good developer can build a solution that looks less complex and is easier to understand than an equivalent Java solution.
As a more capable language, Scala does place a greater responsibility on the individual developer.
At that point you need to ask the question "do I want better developers or more developers?" That is where the interests of a business that uses development tools start to diverge from those of a business that makes those tools.
|
|
|
Is the JVM itself beyond critical analysis? To paraphrase the article, I think it is useful to think about what we've learned from the JVM. What did the JVM wrong? What did the JVM get right? Could we build a better base for 'the next big language(s)'?
|
|
|
> Scala advocates don't like to hear that Scala is too complicated, but it's a fact that this perception is widespread.
If simplicity in the language is the goal then we should all be using 6502 assembler: 1 accumulator and a couple of registers if I recall. Very simple.
All the ports from Java to Scala I've seen, and all the solutions I've seen written in Scala, are simpler than the equivalent Java.
One could probably say the same of ruby and clojure but I don't know enough about them to make a judgement.
|
|
|
I don't think there is going to be a big JVM language in the following years. I also don't think that there is going to be a big language generally. In my humble opinion, things have become stale in the programming languages domain, with new languages being only small variations of the languages of the previous generation.
I think the programming language community is trying to find the best balance between ease of use for the libraries developer and the end user. Which is not bad, I think there is a lot to be done in this domain.
|
|
|
> Is the JVM itself beyond critical analysis?
i second this - the JVM has been widely praised for enabling the current plethora of JVM-based languages, and without the JVM these languages couldn't claim production-readiness and Java interoperability to the extent they rightfully do (with many differences between languages). On the other hand, the CLR has arguably got a few decisions "more correct" than the JVM: generics and the handling of primitive types and true objects immediately spring to mind, as they cause a lot of grief on the JVM and need to be addressed by JVM language designers (e.g., see optimisations in Scala 2.8 for making primitives appear as true objects without losing performance).
|
|
|
> I don't think there is going to be a big JVM language in > the following years.
I agree. Java is going to get some new features, hopefully not tooo many and hopefully without breaking backward compatibility (I can't stress this point enough).
In short, I pretty much agree with Stephen's analysis: Clojure is too different, Scala is too complicated, don't know about Factor or Groovy. But as I said, preserving backward compatibility is critical and that's where I disagree with Stephan.
|
|
|
> But as I said, preserving > backward compatibility is critical and that's where I > disagree with Stephan.
If I understand the article correctly, those who require backward compatibility would stick with "Java Classic" which would continue on its current trajectory. The forked version (Java NG) would be a different language. There would be initial compatibility breakage but it would be wise to continue the backward compatibility guarantee from that point on.
|
|
|
>Or this thread on reddit: > http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmuOh please ... some chap relates a secondhand Scala horror story, possible to get a rise out of the group. Pls don't take that as a representative sample .. -jb
|
|
|
> At that point you need to ask the question "do I want > better developers or more developers?"
I've worked in small, medium, large, and very large development organizations. In all cases, managers vote for more bodies.
|
|
|
I think that Scala has a ton of features that interact in powerful ways, and people haven't really figured out the right way to use them yet. The result is a lot of code that leverages more magical features unnecessarily, and that tries to make everything look like a DSL.
A good example, I think, the Dispatch library mentioned in the Reddit thread. It's a wonder library once you get the hang of it, but ironically I think it's orientation as a DSL makes it much harder to learn that if it was just a library with plain old method names and much more limited use of implicits.
I think there's a certain coolness factor right now in using all these features and making everything a DSL that will fade, and when it fades Scala code will start looking a lot more approachable.
|
|
|
I think most production languages developed in the past 20 years or so made a big step backwards from C++. That's why there are so many of them - every new language is trying to correct something in a previous language because all of them suffer from some fundamental flaws (some more than others). Just look at the generics in Java and C# - it's ridiculous! This industry wastes too much time and effort in designing new languages instead of developing problem-solving techniques. What I'm trying to say is that we should stick with C++, especially C++0x, and forget about the rest.
|
|