Common Lisp vs Clojure
I started tinkering with Lisp when I was in college and was easily tempted by the possibilities. The relationship didn’t last because it simply took too much coding to match the capabilities of the modern programming languages at the time, C++, Pascal and Perl. When I was hired to work on a Clojure project I was excited to see that Clojure was a Lisp technology that could leverage off of modern technologies. This relationship soured when I discovered that Clojure not only doesn’t conform to any standard, but has no intention of ever conforming to a standard. Many will argue that Clojure isn’t proprietary because it is open source, but with a single company controlling it’s development, and no established standard, I argue that Clojure is indeed a proprietary technology that can at any point make fundamental changes which break the functionality of business applications.
Being disappointed with the proprietary nature of Clojure I started looking for a JVM based Common Lisp implementation and found ABCL, Armed Bear Common lisp. While I didn’t particularly like the name of the application, I could see that this technology appears to be on the verge of being usable for modern applications. There were two immediate issues I ran into with ABCL, performance and conformance. Instead of wasting time complaining about these problems I took an active role in trying to repair them. The performance issues were relatively easy to identify. The system runs with a giant call-stack and makes excessive use of the java “instanceof” operator which is a very slow operator that can be easily refactored out of code. I also discovered some issues with file IO, specifically regarding the handling of jar files. What I discovered was that it didn’t take a great deal of work to improve the performance of the language.
If the advantage of Common Lisp over Clojure is that Common Lisp is an established standard than conformance to that standard would be a prerequisite to choosing A JVM based Common Lisp implementation over Clojure. This is the tragic flaw of Common Lisp, and in some ways a well-guarded secret. ‘Secret’ probably isn’t the best word to describe the situation because many of the developers know that their implementation doesn’t conform 100% to the standard, but instead of solutions to the conformance problems the only thing you will find are excuses. Even SBCL which is the most commonly used implementation of Common Lisp fails over 50 of the official ansi common lisp conformance tests. ABCL performs somewhat better on these tests but how far is it from 100% conformance? If passing the remaining tests is any indicator I found that it wasn’t very difficult to get ABCL to pass most of the tests. There were 3 tests that I didn’t solve. Two of the failures are because ABCL doesn’t do strict CLOS type checking, which probably isn’t too difficult to solve, but the third failure is with the pretty-printer, and that is the conformance issue that is unbelievably complex. The complexity of the problem alone can explain why Common Lisp implementations don’t conform to the standard. Digging deeper into the issue I discovered that some flaws in pretty-printer implementations date back over 20 years.
The most fundamental difference between Common Lisp and Clojure is that Clojure is a Lisp-like language, and Common Lisp is an established standard. Choosing a standardized technology over a proprietary one is a fair decision if there is actually an implementation that both meets your needs and conforms to that standard. While ABCL proves that it is possible to implement Common Lisp in JVM and therefore utilize the modern facilities provided by Java, it doesn’t fully conform to the Common Lisp standard. As far as I can tell, none of the freely available common lisp implementations do fully conform to the standard. Sure they are accepted as conformant with the help of documented exceptions, but the reality is none of them comply with 100% of the rules established by the standard. Because of this I must exclude the existence of a standard as grounds for choosing Common Lisp over Clojure. Once standards compliance is excluded, what remains is that Clojure provides an easier to use syntax, better performance, and better integration with modern applications. Common Lisp implementations have a single advantage of being based on a standard, but that advantage is lost by the fact that no implementation conforms to that standard, and without the standard there is no remaining reason to choose Common Lisp over Clojure. At this point at least, it seems Clojure is the clear winner.
