Clojure : The zombie-reanimated corpse of Lisp

* updated 2009-08-21 ** updated 2009-08-20 *


Nowadays it’s frowned upon to criticize anything in society. It’s quite pervasive.
That is unless you happen to also be criticizing the same thing that a group of other people are also criticizing.
We hardly speak our minds, instead it’s more common to take a passive-aggressive and sometimes socio-pathic approach when any type of issue arises. Annoying as they can be there just aren’t enough Zed’s in the world. We’d rather be part of the herd and not admit it to ourselves. We don’t want to be shunned, we don’t want to lose friends, our homes, wives and the stuff that we accumulate.
So we go with the flow at the expense of the dream and what is better in the long term. After
all everyone’s been doing just that since the beginning of time right ? And besides
won’t we make more money if we just go along with everyone else ? Hardly, look at
the current state of the world economy. Astonishing even as we’re told to buy that it’s looking better, it has to, we don’t want to believe the alternative.


On that note, this is my satiric rant regarding what many are hyping as the future of Lisp, so be warned.
I dedicate it to the Zed’s of this world. It’s abrasiveness is meant to counter the ‘mega-hype’ that accompanies Clojure’s sales pitch. Clojure is not worthy of the Lisp name. It is the antithesis of the Lisp machine in every way. It has little regard for the intellectual rigor and cohesiveness of Lisp.

Whether it’s author and followers are even aware or willing to acknowledge this :
Clojure has inherited many of Java’s idioms and problems.
Clojure is not only built on top of the JVM. It is also built on the Java language.

For better or worse this means that many Clojure types are Java types underneath.
This is a fundamental and idiomatic clash in Clojure’s type system and this effects the way that software can be written in Clojure. Java is an imperative language while Clojure is a ‘trying much too hard to be pure’ functional language. Clojure is hyped for it’s immutable strictness of local variables to the extent that some refer to it as if it’s a ‘silver bullet’ for issues related to writing software for multi-core platforms (STM etc.).

It’s dictator doesn’t provide much of a reason for enforcing the immutability of local variables. Yes, I’ve read the long thread on CLL that ‘explains’ some of the reasons. I’m still not convinced why concurrent programming support had to be implemented at the language level. The focus on concurrent programming assumes much in the way that immutable types are forced on the programmer unless they decide to stoop to using Java’s mutable types.

Why not simply add support for concurrent programming as a library instead ?

Why not provide both immutable and mutable versions of the same data types ?

Why not let the programmer decide what paradigm works best for themselves ?

The reasoning for implementing Clojure on the JVM is understandable, there is much that the JVM has to offer : memory models, GC, overall maturity etc.
The hype about ‘getting all that for free’ is very optimistic. The JVM was designed specifically for the Java language, so draw your own conclusions.

That seems to be changing more recently
. Supporting other languages on the JVM may turn out to be ‘a good thing’ depending on what your favorite language is on that platform.

There are an abundance of Java libraries that Clojure fans will be glad to have access to now.
The hype about having access to all these libraries ‘for free’ is ironic. Many Java libraries only exist
due to limitations of the Java language itself. Also when writing real-world software, what about the effort required to align the multitude of Java libraries that assume an imperative environment with Clojure ? Can these libraries be used easily, safely and with the same performance ?
You just have to picture all the newbie Clojure programmers when they hit this wall.
No problem right ? They can just wrap all the imperative Java libraries using their newly discovered hammer : macros. Hopefully many of these old libraries are used only as a bridge until they are replaced by more shorter idiomatic functional versions.

Clojure introduces new problems(ok ‘challenges’ if you will) having discarded enough of the last half-century
of Lisp progress. Sure, Common Lisp has it’s problems but hailing Clojure as it’s future is a new low in the community. Another lisper put it so bluntly :  “Clojure is the gutted and zombie-reanimated corpse of a dream.”

If anything, Clojure is hopefully the future of the JVM. It is definitely a step up the language continuum, for those who decide to move from Java to Clojure.

The hype, guru-worship, immaturity of the language and the benevolent dictatorship of Clojure are rapidly catalyzing something in the world of commercial software development. This can be an indicator of trouble ahead. There’s good reason that Haskell’s motto has long been “Avoid success at all costs.”
Clojure is popular right now and in a few years it’ll be used in common “tech” speak by clueless managers
and inexperienced programmers who consider Clojure their first exposure to a functional “Lisp”.
Many of us will inevitably be using Clojure in our day jobs in the same way that we currently have little choice in
using whatever the required and popular lowest common denominator is at a company.
At least Clojure is a real improvement over the status quo, I can appreciate that.

2 thoughts on “Clojure : The zombie-reanimated corpse of Lisp

  1. Clojure seems to have attractted too many people who don’t know how to think for themselves (the guru-worship as you said). The language has some nice features, but there are also a lot of problems, some of them are very basic flaws that other languages have long got over with. As a new language, that may not be anything particular unnusual. What is unnusual and lowers my prospect is, the current self-feeding hype turns people blind to those problems.

  2. Pingback: Clojure’s growing popular mind share | imagine27

Leave a Reply

Your email address will not be published. Required fields are marked *