Alternate languages on the JVM?

I’m trying to summarize several discussions about alternate languages on the JVM that I absorbed at the No Fluff Just Stuff conference. Can I become a language evangalist based on a weekend at a conference? I suppose not, but there were a lot of compelling arguments for why we should be looking at some of these new functional languages on the JVM. It was put forward that most of the reasons we like Java have to do with the JVM and not with the Java language:

1. Cross platform
2. stability
3. Performance
4. security
5. huge world of libraries

These will hold true with any language that compiles to the JVM.

Why are they even considering new languages? Multiple reasons bubble up from conference as a whole.

Extensibility.
Discussed the example of hadoop. It is an open source framework that handles huge amounts of data in a distributed way. It is inspired by Google’s MapReduce papers. They evidently found some of the core java classes insufficient for their needs. If you look at the docs for org.apache.hadoop.io.text, it says, “It provides methods to serialize, deserialize, and compare texts at byte level…. In addition, it provides methods for string traversal without converting the byte array to a string.” Does this point to an extensibility problem in Java? If not, why couldn’t they reuse any code from String? Someone at the conference asked why can’t I make Object define toXmlString() so that every one of my classes that descends from Object automatically has a toXMLString() ? This is extensibility and Java doesn’t do it as completely as some other languages might.

A language shouldn’t limit what you can do. Certain language constructs not available in java (closures, switch statements, folding) enable developers to be far more efficient.

OO might be failing us. We try to think of Objects as changing in place. Rich Hickey, the creator of Clojure, rejects this: ” The future is a function of the past, it doesn’t change it. ” If we stop thinking of data as persisting and changing over time and instead recognize that a thing is immutable and when it changes it becomes a different immutable thing. Like a date, or an account balance. The state of an account a point in time is immutable. Adding money to it does not change it, it creates a new state. This 55 minute video of Rich Hickey explaining some of these ideas was recommended at the conference and is amazing. As he explains, all of our concurrency problems come from the notion of objects changing in place.