Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 221 posts at DZone. You can read more from them at their website. View Full User Profile

Do we need other languages on the JVM?

08.01.2011
| 6000 views |
  • submit to reddit

It seems a trend has caught on and accelerated recently: every organization worth his salt in the Java ecosystem feels the need to create its own language that runs on the Java Virtual Machine. Side by side with legacy languages like Jython and JRuby, and along more promoted ones like Scala, Red Hat announced Ceylon and now it’s JetBrain’s turn with Kotlin.

Why so many languages?

However, the real question is not whether we need them (the answer is a simple ‘no’ since we created software without them), but why there is a sudden rise.

The developer perspective

Truth to be told, Java is an old-timer in today’s changing world. I began Java 10 years ago and I was not a pioneer at the time. Java the language’s evolutions has been hindered by:

  • a lack of competitors prior to .Net
  • a requirement of compatibility with older versions
  • a change process that encompassed companies with divergent interests

The mixing of the three makes any update on the language a real challenge. The last major change dates back to Java 5, which is End Of Life…

So, instead of following the slow Java path, some developers prefer to use the highway to features not present in the language, such as Scala’s functional programming.

The new leader of the pack

Although I have a clear view why developers may want to use languages other than Java on the JVM, I can only speculate as why companies are releasing them. IMHO, big players in the Java ecosystem are afraid of Oracle’s control over Java and are trying to escape potential future costs of using Java. It’s a real risk considering Oracle’s stance on TCK as well as the Hologic fiasco.

Risks posed by other languages

Although the previous reasons are in favour of language diversification, there also are some strong arguments agains their uses.

Skills management

The Java ecosystem is very rich, and one doesn’t just qualify as a Java developer, but as a Java/Spring/Hibernate developer for example. In the event of a coming of other languages, recruitment will be even harder. And from a developer perspective, skills needed will be more widespread, thus leading to a decrease of knowledge in each individual language (no, you cannot be a master of many languages).

Loss of weight

Today, the market can roughly be divided into Java, .Net and PHP. I agree that others exist but frankly, they do not count as major players (Flex excepted but it’s staying on the GUI). If the Java language gives way to a bunch of other languages, however fantastic they are, the Java community as a whole will be fragmented into many tiny communities that won’t play nicely with one another. Notice that it’s beginning to happen if you read the comments on Ceylon, some definitely look like a war waiting to happen.

Other cases

In the previous sections, I deliberately left out some cases that are sensitive. I don’t want to start a flame war but since I tend to disagree with some of them, here are my counter-arguments.

LOC

Some complain about Java verbosity and choose a language that will make them write (and read) less code. Although I agree that it’s more maintainable to write 10 LOC against 100, I don’t see a problem in writing 15. I respectfully remind everyone that not every developer is top-notch and that writing explicit code (and reading it) goes a long way toward having maintainable software.

For those obsessed with LOC-optimization, I gladly provide this contest.

Operator overloading

Java doesn’t have operator overloading. Again, this is not a problem, at least for me: this means I can count that 1+1 does what I expect, and not another circonvoluted operation. As a counter-example, just have a look at Scala Akka’s bang operator (for newbies, there are also bang bang and bang bang bang). Sure it’s short but you really need to know what it does. If it’s the only library you use, that’s fine; if not, you’re headed for a world of doubts.

Technical vs business

Only the future will tell but I’m afraid the trend is that languages going to go beyond a nice are ones that free developers from purely technical tasks with no business value, such as memory management, portability, persistance, and so on. Do the former two ring any bell? Java surfed on them. Powerful or hype are adjectives that managers don’t care about. Since they are in position to decide, I think that because a language can do more than another has no interest other than a educational one.

Conclusion

For now, my point of view is that negative points against all these new languages are not counter-balanced by positive ones. Of course, I’m a pragmatic by heart so I’m all ears if I’ve missed a point. In the end, though, only time will tell.

 

From http://blog.frankel.ch/do-we-need-other-languages-on-the-jvm

Published at DZone with permission of Nicolas Frankel, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Scott Hickey replied on Tue, 2011/08/02 - 10:55am

This essay has been already published in various forms many times over the past several years, in DZone as well as other places. This isn't a "recent" trend.

Instead of repeating the detailed responses that have written many times over the last several years, I offer the following:

Those who have actually used other JVM languages, such as JRuby and Groovy, over the past 6+ years on real projects, know from experience there is tremendous business value in doing so. Those who haven't write articles like this.

The "Blub Paradox" as explained in Paul Graham's "Beating the Averages" is a great article that explains why many developers don't "get it" when it comes to other languages on the JVM.

Jan Kotek replied on Tue, 2011/08/02 - 3:15pm

This is just gibberish. I wish I got back those 10 minutes I spend reading it.

Nicolas Bousquet replied on Tue, 2011/08/02 - 4:18pm

But what you say is like Scott Hickey says you have the blub syndrome. Whaever is not blub language doesn't suit you because it isnt the one you use and master. You criticise thoses obviously less advenced as being less capable... and thoses more advanced as providing useless and error prone features. Out of the dozens language out there it just have that you know and use the best compromise, luky you. And all other that prefer their own language are obviously wrong.

It's remind me of Java before generics. Many argued that not having generics or templates was indeed a feature. They used all sort of arguments. This continued a little, while the same people add difficulties praticing with JAVA 5. Now a few years later we have some saying that java 5 template are not as good as C++ or some other templates languages... But nobody say that we would be better without templates anymore...

I not for very similar languages that basically do the same things and just add another dialect. From your example of Java/C#/php obviously Java/C# are very similar. C# still being appear supperior than Java (I'am a java developper for a leaving if you mind), and the JVM being better than the CLI. Instead of the best of both word, we have to choose. And the community is fragmented for no good reason. It is more about politics like 2 companies wanting to have their language than any other argument. Like Jetbrain with it's new language.

But there are really better and differents languages, concepts. And just sticking with C#, java or whatever is making you miss the concepts, way of thinking alternatives languages provide.

This make you writing more verbose, less explicit and more difficult to maintain softwares. For the LOC, most study agree that the more LOC you have (or tokens if you prefer) the more complex your program become, and the more costly it is. The cost is exponential.

So 1,5 more line of code is not x1,5 the effort, but x^(1.5) the effort. For me this fact was intellectual. But now I work on a very big company with dozen millions LOC. I see that to add similar functionnality we need like 10-20 time the effort for similar task than when I was working on a small project. I know that LOC do matter.

One last argument...

I think you would agree that java/C# do provide some progress against x86 assembly. And with the higher concept, you can say rougly the same thing, focussing less on low lever technical parts (like using CPU register for improved performance) and reducing by a good amount the number of lines.

This is the same languages like scala, lisp, python... do provide against java. Maybe we have too many, but we sure need at least hal of theses alternatives languages anyway.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.