Archive | May, 2010

Why Clojure?

27 May
Tools and languages do matter. Functional programming matters as well. To see why read why functional programming matters . Recently decades old ideas started slipping into Java land. Initially Scala, then Clojure gave Java programmers a choice of radically new languages running on top of solid and time-tested JVM. I briefly played with Scala, nothing resembling a real project, but when Clojure came out I knew it is time to get my feet wet. So, why Clojure? Here are the reasons in priority order.


1. Seamless interoperability with Java.
Calling Java from Clojure is easy via syntactic sugar coating. Any Java library is available right way. Clojure collections implement Java collection interfaces and are thread safe. Clojure functions implement Runnable and Callable. As a consequence, selling Clojure to your hairy-pointed boss becomes easier. It goes something like: functional languages are cool and are cutting edge at the moment, Clojure runs in JVM and can easily reuse our existing code base, etc. Let’s use it for non-mission critical components first.


2. State is immutable by default.
Writing complex concurrent programs in Java is hard even with Java 1.5 high level concurrency API. In contrast to Java where mutable state is a default and norm, Clojure defaults to immutable state. There are four flavors of explicit mutation API. Since one can’t get away from having a state and side-effects in any nontrivial program this leads to a design decision of splitting a program into immutable and mutable parts. Obviously, it will make sense to maximize the former and minimize the latter. Immutable part tested in REPL and/or by Clojure/Clojure-contrib test facilities is guaranteed to work every time in most complex call chains. This is a HUGE. To parallel this to Java let’s imagine that you only have to write unit tests. No need for integration and even regression tests – your unit tests assert that functions inputs and outputs behave as expected so combining them should work as well.


3. Macro facility extends language to your needs.
No more waiting for language babysitters to add this or that. You need a language construct to solve your particular need – use a macro. This also gives you a competitive advantage over others who use more rigid and verbose OO languages. That is what Paul Graham meant in his revenge of the nerds, a must read.


4. Other goodies: lazy-sequences, multi methods, software transaction memory, REPL.
Let me mention a drawback as well. As other dynamic languages Clojure lacks  strong typing.  It is dynamic language with support for type hints via metadata. Type system purists would argue that this is a crucial flaw. I agree to a degree. Yes, compile time checking is important but no sane person would run a Clojure without testing functions/parts in REPL. Plus, if you are writing unit tests, I do, you have another level of defense.
In the next post I will get my feet wet, writing a binary search in Clojure.