How innovative is Clojure as a Lisp dialect from Lisp expert's perspective?
I think I am qualified to answer this: I wrote reasonably complex systems in Common Lisp before I gradually moved to Clojure several years ago. I have written several fairly large apps and systems in Clojure and Clojurescript (this includes <a href="https:&#x2F;&#x2F;partsbox.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;partsbox.io&#x2F;</a> as my current project and apps like an e-commerce search engine processing hundreds of requests per second for many years).<p>I used to think Common Lisp was a fantastic language, but I always tried to keep an open mind remembering the Blub paradox. Then I started working with Clojure and after the initial friction (some things were just plain annoying in the beginning) things clicked for me. It was, quite simply, a much better language.<p>The major improvements over Common Lisp for me were: 1) immutable data structures: these days I can&#x27;t even imagine dealing with code that mutates data in-place, 2) a great approach to concurrency and parallelism (it&#x27;s really difficult to get yourself deadlocked in Clojure), 3) Rich Hickey coming out every year or so with a solution to yet another problem (core.async, transducers, spec), 4) really flexible data structures.<p>I know there are many CL advocates who will try to point out that CL has all these things. But these will be the same people who will be annoyed when Java programmers point out that Java has all these things, too. It&#x27;s just a matter of friction, elegance and ease of use.<p>One additional factor which is often glossed over is Clojurescript. Most software these days exists in some form in the browser, too. Being able to use pretty much the same language (cljc files can be compiled both server-side and client-side to Javascript!) on both sides brings many advantages.<p>People sometimes ask me if I miss CLOS or the MOP. Not at all. It&#x27;s a great set of concepts, worth learning (the green book makes for great reading). But I found that larger systems using CLOS were really difficult to understand and follow (just following the code flow is a nightmare if you have a lot of multimethods), and systems that used the MOP in any but the most basic ways were intractable without a debugger. Besides, please see above what I wrote about immutability: I&#x27;d much rather have immutable data structures.<p>Clojure&#x27;s emphasis on functions and data, while it may be based in the 60s, is one of the really good ideas. And Clojure is really, really good at tackling complexity, it&#x27;s just not apparent in the language design. While other languages focus on syntax sugar, Clojure&#x27;s focus is on getting things done on a large scale. You don&#x27;t see that, but things like namespaced keywords, clojure.spec, pre&#x2F;post conditions, maps, sets, all play together to allow you to create extensible and reusable code.<p>Also, it&#x27;s easy to discount certain solutions in Clojure as &quot;also existing&quot; elsewhere, but without actually using them in real systems one often doesn&#x27;t see the full advantage. Transducers are a good example: I think they are under-appreciated and under-utilized. Common Lisp veterans will laugh and say that SERIES did the same thing back in the 80s. But SERIES was all about optimization and anyone who actually tried to use it will have stories to tell about how easy it is to use. Transducers, on the other hand, if used to build data-processing pipelines processing Clojure maps with namespaced keys, are an elegant and efficient tool for building composable systems. Plus, once you&#x27;ve coded your pipeline using transducers, it&#x27;s a snap to parallelize it.<p>Looking at it differently: to &quot;get&quot; Clojure one has to understand that there is no silver bullet: no single revolutionary &quot;feature&quot;. Instead, the gains come from tiny improvements all over the place: immutable data structures, good built-in library for dealing with them, core.async, transducers, spec, Clojurescript, not having to convert to JSON or XML on the way to the client, re-using the same code on server-side and client-side, and more.<p>In practical terms, I would never be able to write and maintain by myself the system I&#x27;m currently working on (<a href="https:&#x2F;&#x2F;partsbox.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;partsbox.io&#x2F;</a>) without Clojure and Clojurescript. It isn&#x27;t impossible, but I can&#x27;t imagine tackling the complexity in a comparable time frame.<p>I can&#x27;t imagine going back to Common Lisp. I sometimes have to look at the code I&#x27;ve written in CL, and it looks clunky. Especially place-oriented programming (setf all over the place) is something I really really don&#x27;t want to go back to. It&#x27;s a nightmare, particularly if you intend to have any kind of concurrency.<p>I still try to keep an open mind, remembering about the Blub paradox. I make it a rule to regularly check and learn about new languages. There are some which I found really good for certain types of applications and which I would use instead of Clojure in certain cases (Elixir is a good example). I still haven&#x27;t found anything comparable which is a general-purpose language, especially if you consider the client-side story — but I&#x27;m checking all the time<p>See also my answer to a similar question posted on Quora several years ago: <a href="https:&#x2F;&#x2F;www.quora.com&#x2F;What-do-veteran-Lisp-programmers-think-of-Clojure&#x2F;answer&#x2F;Jan-Rychter" rel="nofollow">https:&#x2F;&#x2F;www.quora.com&#x2F;What-do-veteran-Lisp-programmers-think...</a><p>Also, as a general observation: most (not all, but most) criticism of Clojure seems to be written by people who did not write anything significant in it, and much of that by people who simply do not write large software systems at all. Reading many discussions, I gloss over most comments, as they are simply beside the point and not even worth addressing.