Real World Comparison of Scala and Clojure

Tonight, I attended a presentation by Robert Rees (the podcast available here), from the Guardian Newspaper group, comparing his experiences with both Scala (which is being rapidly adopted by the Guardian, along with MongoDB, to replace their Java/Oracle technology base by the years' end) and it's functional competitor Clojure.

I'll just write a little bit of context for those who aren't too familiar with what all the fuss is about.

Usually, when you make a piece of software that runs on an operating system, such as, say, Windows or Android, you have two pieces of software, a compiler and a linker, that turn the code into an executable, which you can then run. Most pieces of software are done like this, from my noddy little exercises in C for college up to Microsoft's Office suite. About fifteen years ago, a group of programmers at Sun Microsystems, in the U.S., came up with the idea that you can separate the executable into two halves: the first bit would be the specific code to do a particular job and the second bit to be more general that would manage the communication between the specific bit and the operating system (the idea wasn't theirs, exactly, but the way they were going to use it was). This bit, or layer, was called a "virtual machine" and it could be re-written for any operating system in such a way that the specific program could be run on any virtual machine without having to be re-compiled, what Sun called "compile once, run anywhere". Thus the Java Language and the Java Virtual Machine (JVM) were created. The Java compiler produces something called "bytecode", a sort of half-way house between code and executable, that can be run by the JVM. In theory (although not an idea immediately taken up by Sun) any language, not just Java, can be turned into byte code by a suitable compiler to be run by the JVM. Unfortunately, Sun jealously guard the definition of byte code, which is the interface to the JVM and how it works, so that no-one can produce another language which runs on the JVM (and can compete with Java, and Sun), unless Sun say so. The same also goes for the JVM itself, thus the first JVM for Linux was made by Sun, not the open-source community.

Skip a few years and up come Microsoft. They've adopted the same idea a few years earlier for their Visual Basic language, but it's not particularly well done. They have a word with Sun about creating a version of Java for Windows. Sun say "ok, but we're watching you!!" (Microsoft being a large corporation with a somewhat mixed reputation, both technically and commercially). Microsoft create their own version of Java, called J++, and a virtual machine to match, but there's a few cross word from Sun (in the form of a legal suit) as they don't like what they see (surprise, surprise). In the fallout, Microsoft create .Net, which is their collective name for both the new Windows virtual machine, the code libraries that go with it, and a load of related (and, some might say, unrelated) technologies. The .Net "VM", called the Common Language Runtime (CLR), is so optimised for Windows, and so pervasive, that almost every executable on Windows now has to use it. Microsoft, like Sun before it, also produced a Java-like (and improved) language, C#, as well as adapting Visual Basic and Visual C++ for use with this new technology.

"OK", says you, "but what's this got to do with Scala and Clojure?". Well, one of the things that Microsoft did is open up the .Net interfaces and, in particular, the definition of the .Net byte code, called Common Intermediate Language (CIL). This means that anybody with sufficient skill can implement a .Net compatible language compiler. This didn't have much of an impact, at first, but in reaction, Sun decided to go one further and open-source most (but not all) of the JVM, an almost complete reversal of the previous policy. It's a bit baffling as to why, but Sun were having financial problems at the time and were subsequently taken over by Oracle, so it might have been something to do with that. Anyway, this openness means that, like .Net, people with sufficient skill can produce new languages for the JVM, and this is what Scala and Clojure are.

Both Languages implement functional programming, but Scala implements both functional programming ideas and object oriented ideas, like those in Java, C++, C# and Delphi. Clojure, on the other hand, is an implementation of Lisp, a mathematics-based language using something called Lambda calculus (invented by Alonzo Church and the basis for functional programming) and one of the oldest programming languages.

Robert's presentation, done in a friendly and relaxed style, took us through the two languages and compared their various features. Although he seemed to prefer Clojure, he admitted that it had some problems which might be difficult to overcome in an environment where Java, or a similar language such as C#, was established. In that case, Scala might be more easily adopted, despite it's more compromised implementation of functional programming.

However, he also highlighted the future release of Java 8, which is puported to have Lambda extensions, and might make adopting Scala or Clojure moot. Also interesting was his theory that if Microsoft implemented similar features in C#, F#, it's functional programming language, would similarly be redundant.