Pinderkent

Today I read Kevin Smith's recent article entitled Erlang Doesn't Fit The JVM. As the title suggests, he discusses why efforts to port Erlang to the Java Virtual Machine really wouldn't be of much value. In general, I tend to agree with his points. The JVM does indeed lack the necessary functionality that makes Erlang particularly valuable.

Unfortunately, I think he missed discussing one of the major arguments often used in support of having non-Java programming languages target the JVM, namely that of reusing existing Java code. The Scala homepage, for instance, currently mentions in its introduction to Scala that "Scala has the same compilation model (separate compilation, dynamic class loading) like Java and allows access to thousands of existing high-quality libraries." Likewise, the Clojure Rationale page lists the reuse of existing Java code as a necessity: "Ability to call/consume Java is critical." Thus we can see that code reuse is one of the driving factors behind these new languages targeting the JVM.

Code reuse is one of those things that sounds great, especially to managers. But in reality, however, it's often of somewhat limited value. That's not to suggest that all code reuse is bad; clearly it isn't. There is little point in having developers today write basic string handling code, or common math functions, and so forth. But once we start getting into application- or domain-specific code, reuse starts to become less useful, and can often become quite a problem.

I think this becomes even more of an issue when trying to integrate code written in one language with that in another. This is especially true when one language (such as Scala) offers higher-level functionality and concepts much in excess of the other language (Java, for instance). Libraries and frameworks written with Java in mind very likely won't be designed in such a way as to make the best use of the language features and approaches that Scala, for example, makes possible.

The same goes for Erlang. One of the main reasons why we may choose to use Erlang over Java is that Erlang brings a set of concepts and solutions that, at the language level, just aren't offered by Java. In many ways, the general principles of Erlang-based development don't mesh well with the Java philosophy. This is evident at the very basic of levels, where Erlang embraces immutability, while mutability is widely used and encouraged within the Java development community. Likewise, lists and tuples are first class language constructs in Erlang. But when using Java, one has to resort to arrays or classes wrapping arrays to reproduce the functionality of lists. The Java equivalent of a tuple is usually just a class with several member variables. And while an Erlang developer will typically use recursion to iterate over a list of values, a Java programmer would likely use a loop. Things become even more complicated and mismatched when we consider how Erlang's approach to concurrency and distributed computing can be somewhat emulated in Java, but it isn't as natural as it is in Erlang.

When trying to combine the Java and Erlang philosophies, or more generally when trying to combine traditional imperative and object-oriented techniques with those of functional programming, we often run into the so-called "impedance mismatch" so often seen between object-oriented class hierarchies and database-based relational models. So the concepts of Java and Erlang can be mixed, but they often come together poorly, assuming the outcome is even usable.

While languages like Scala and Clojure, as well as an implementation of Erlang for the JVM, might allow for interoperability with existing Java code, the practical benefits likely don't exist. On one hand, we can choose to reuse existing Java code heavily, but at a cost of not making use of the new and often productive features of the newer, non-Java language. At that point, we might as well just go back to using Java. On the other hand, we can heavily use the language features of languages like Clojure, Scala and Erlang, and make a more minimalistic use of existing Java classes. Unfortunately, this will likely just lead to interoperability hacks, which can become maintenance headaches down the road. Trying to find a middle ground will just result in lost functionality, or an increasing number of hacks.

When moving to a new paradigm of programming, we sometimes just need to admit and accept that we shouldn't try to reuse our previous code directly. We're likely moving to the new paradigm because we need to increase our productivity in order to remain competitive and viable. And while reusing our existing code may initially sound like a good idea, it will only serve to become an anchor. A better idea is to keep in mind the knowledge and experience we obtained while developing the older code, but to put the focus on using the features of the new language or languages to our best advantage. This likely will mean reimplementing existing functionality, but doing so with a new philosophy and mindset. And so we'll make true progress by applying new ideas to existing problems, rather than by trying to convolute our existing solutions and ideas into the new way of thinking. It just doesn't make sense to cripple a powerful and advanced language like Erlang just for the sake of reusing some existing code.