Analysing Clojure programming language - Why it comes so near, but not too near?

Friday, December 11, 2009
Clojure is a multi-paradigm language. It is mix of imperative, functional and object-oriented programming. The parser, compiler/interpreter and runtime uses the Java Virtual Machine. Let me not get into any more details. The Clojure site is the best reference.

Functional programming finds its best implementation in the homoiconic language family. Clojure being a LISP (there is the LISP family and dialects like Scheme, Common Lisp, now Clojure) is homoiconic. The syntax in the LISP world is based on s-exprs; for the unitiated and haters it means the program looks like a big list of matching curly braces. Unlike Scheme, which strives towards minimalism, Clojure embraces expressionism. Traditional LISPs provide data structures as macros, functions or libraries. Clojure provides all this and in addition wraps them in syntactic sugar. I am biased towards Scheme's minimalism, but that is just me, and my fellow ivory tower academic hard-heads. This is not a shortcoming of Clojure. The goal of Clojure was to provide practical constructs for data structures and not just s-exprs.

There are however, a couple of idiosyncracies in Clojure which are distracting. Some of them create the feeling that "there is something wrong". Similar to Trinity fearing Neo's deja-vu on seeing the cat. I believe that these idiosyncracies need to be ironed out, maybe even eliminated. That will make the language mature. More important, it will make Clojure accepted outside of its niche community.

The attitude of the language and to a certain extent the language community is to be a better Java with functional forms. In this respect one will not appreciate Clojure for being a better LISP. Instead Clojure tries to be a better Java with LISP syntax. The documentation, the Clojure book (Programming Clojure) are never aimed towards a developer who wants to program. Instead it is addressed towards specifically Java developers, selling them the features of Clojure which is better when compared to Java (though the book says it can be used by experienced Python, Ruby, etc developers). Yes, this will help in attracting people who are Java cats who are searching for an ideal functional programming language. No, this will not make the language popular. If you look at Python or Ruby which also have Java based environments, the first class citizen is the language of Python or Ruby itself. Java is for performance and its large library. In Clojure it sometimes feels the other way around. Please note that I am not complaning about the language design here. I point at the attitude and the stance of the community.

Owing to the above attitude, many of the language constructs exist so that one can do what Java cannot do. The language introduces constructs because it cannot be achieved in the Java VM. For e.g. tail calls cannot be optimized in the Java, so we have recur and trampoline constructs. Obviously us Java developers will buy into it. But functional developers will never buy into that. Any programming language should have its own identity. In Clojure this identity is lost, because practical implementation difficulties are put ahead of clean design.

There is the PERL philosophy of "There are many ways to do it". And there is the Python philosophy of "There are many ways to do it, but there is one right idiom (pythonic)". Clojure is a mixed bag. There are many constructs - functions and macros - which achieve the same thing and you are encouraged to do; there you have the PERLish influence. However the functional programming principles of Clojure state that you should avoid direct recursion, or recur in place of sequence api; which is a pythonic attidute. Definitely the language community should have a stronger philosophy of their own.

I have read elsewhere Rich Hickey's comments on SICP. He says
And I don't think the core of Clojure is appreciably bigger than
Scheme's. What do Schemers think?
A lot of Schemers (including me) will have to spend a lot of time evaluating Clojure before we come to that conclusion. If the Clojure community can re-arrange their thoughts, as well as make those thoughts explicit, maybe then Clojure will be appreciated as being minimalist. Until then someone looking at the language will come away with the feeling that it has a very large core. That will definitely drive people away. (BTW Rich the only reason I was able to understand Clojure is because I know Scheme. I think others will agree.)

In summary if Clojure
  • Tries to break away from being a better Java
  • Establishes its own identity in the design of the language
  • Improves its documentation, so that it can talk to everyone and not just seasoned Java developers
  • Popularises the scaffold on which the language is designed - a small core, special forms, macros, the rich Clojure library, the Java interop and using Java libraries
it will definitely go mainstream. Not just Java developers looking for an alternate language, but Python/PERL/Ruby programmers, the newbies, and finally the enterprise developers/architects will give it a serious look, discover its merits and adopt it. I for one would surely be thrilled with this new LISP with the vast library of Java.

Disclaimer:
I am not a clojure developer. I am a programming language enthusiast and have learnt multiple languages with different programming paradigms; just for the fun of it. Programming languages which I know are Java, Python, Scheme, okie-dokie PERL, C# which for me is Java with a different library and idiom, C, C++ including the (in)famous STL, COBOL & FORTRAN purely because it was in my syllabus, Javascript both in its prototype and functional forms. I have tried to be unbiased; if it exists it might be due to my stronger background in Java, Python, Scheme.

I have reserved my analysis to the language and the language "attitude". I might post more on the libraries, concurrency, macros etc once I trudge through them.