Clojure is not a Lisp

To call Clojure a Lisp is not correct. Using parenthesis doesn't make a language a Lisp. Lisp has few properties, such as uniform evaluation rule, one underlying list structure of both code and data (lisp expressions are lists) etc. Clojure breaks lots of Lisp's rules and syntax, especially by introducing vector notation for the elements of its special forms - defn and let are obvious examples.

To call Clojure a Lisp is the same mistake as to call Ruby a Smalltalk.

In contrast to a Lisp philosophy of uniformity, Clojure is a mess of special cases due to contradictory design decisions of using different collections in one, generic way. What is much worse, lots of special cases are implicit ones - vectors aren't vectors, list aren't lists. In fact, each data type is somehow re-defined and unfamiliar. If something looks like a vector in REPL it doesn't mean it is, if something looks like a list, it could be something else.

Adding these Clojure's own data types, which are based on Java's standard classes, into what is supposed to be a dialect of Lisp, and making them appear as (look like) familiar lists or arrays is that defines Clojure as NON-Lisp. Adding specialized types into a Lisp ruins it. Lisp is its general evaluation rule, plus very few special forms, while Closure is a mess of subtle special cases and design decisions one must be well-aware of.

It would be more appropriate to call Clojure a JVM scripting language with immutable data types and parenthesized, Lisp-like syntax. It is, indeed, sometimes looks like Lisp, and sometimes acts like Lisp, but it is NOT a Lisp. It is a different language of its own. For example, (:a {:a 1}) or ([1 2] 1) are correct Clojure's "function calls" but total nonsense according to Lisp rules.

The fact that some generic functions returns nil, and some "the empty collection" being applied to the same thing is annoying, and distances Clojure even farther from what we used to call a Lisp.

Nevertheless it is very clever language, and I mean it. Basically, we could describe it as a clever mix of well-known and clever syntax elements, such as python-like comprehensions, ML-like function's argument matching, etc. along with standard idioms from both Functional and OO worlds - high-order generic functions, name-based interfaces, subclassing, iterators, etc.

There are some very clever syntax tricks one should appreciate. Java inter-loop via . (dot) operator is a good example. Simplified pattern-matching for fn and let bindings is another cleverness. EDN format - a subset of s-expressions, which looks much like parenthesized yaml is also nice.

Actually, leaving aside its claims of being a Lisp and forgetting for a moment that disgust towards co-called Java-world, this project is a true masterpiece of a very sharp mind. The more you understand it, the more you realize what a clever job has been done here and appreciate the broadness of author's knowledge of programming concepts and techniques.

There are some stylistic nuances, such as using ~ instead of comma for unquoting, or that (recur ...) ugliness, or strangeness of cond, but they are easy to tolerate.

If, for some reason, you've stuck with Java, use Clojure. It will bring back the joy of programming.

Last modified 7 years ago Last modified on Jul 30, 2013, 8:35:31 AM
Note: See TracWiki for help on using the wiki.