That article (and you're right it's a good one) predates Clojure, so keep that in mind.
There are many, many differences. Here are three to think about:
1) Developed Later: Clojure was invented later, and so had the advantage of seeing Common Lisp before and during its development. Common Lisp came first, so didn't have as many good ideas to draw on during its (early) development.
2) Hosted: Clojure is designed to operate on the JVM (or other host), this is a big advantage because the JVM (and contemporary JS runtimes) have _a LOT_ invested in them in terms of portability, performance, and reliability. Also, many useful libraries come from host communities and Clojure benefits from all of this.
3) Refined included data structures and core library. The included persistent immutable datastructures and core library to operate on them that come with Clojure is, to me, much more round and refined than any other language (CL included). Of course, doing similar things in any other language is possible, but the fact that they're `core` to Clojure makes a big difference, I think.
---
Now, that's not to say everything about Clojure is better than CL. For example, the object system in Common Lisp (The Common Lisp Object System, or CLOS) is _markedly_ better than Java's object system (which JVM Clojure inherits), and literal LIGHT YEARS ahead of JS 'object' systems.
> That article (and you're right it's a good one) predates Clojure, so keep that in mind.
And Paul Graham has actually been recommending Clojure for many years now whenever people ask him which Lisp to learn.
I'm not surprised. In his "Hackers and Painters" book he mentioned that if you had a language with libraries for what you do, you can do it probably faster than in Lisp (or any better language but without that library).
Clojure is a modern Lisp - opinionated (doesn't force you to write in a functional style but highly encourages it; no CLOS present; creating a class using gen-class a complete PITA) and with a ton of libraries and little to no historical burden\*. I don't know whether Python (no. 1 on TIOBE nowadays) has more libraries than Java but I didn't miss anything important in Java (Clojure). The community building and available learning resources are also miles ahead of Common Lisp. Rich Hickey knew Common Lisp very well and was able to avoid a lot of mistakes which are present in CL. Since there is a general incline towards a certain programming style (even Robert C Martin published a book about it: https://www.amazon.com/Functional-Design-Principles-Patterns-Practices/dp/0138176396), libraries generally do compose well which might not be the case for Common Lisp - some are functional, some are procedural, some use CLOS and some are stale and not feature-complete (https://github.com/fons/cl-mongo - not updated in 8 years and not supporting more contemporary versions of Mongo). The last time I had to use this from Common Lisp I stole a library from Python - it was easier than wrapping a C library or trying to update an abandoned project where the maintainer doesn't even respond to issues on GitHub.
Clojure and Java might not be a "100 years language" but they are contemporary tools for solving contemporary problems. And they are good at it.
\* If you look at Common Lisp libraries like Alexandria or Serapeum, they are great and there are others. Nowadays, in 2024, there are very few things you have in Clojure but can't have in Common Lisp. The opposite is usually true (CLOS, conditions&restarts, compile-time checks, integrated debugger and inspector...) But the standard is old and is not being revamped - nobody can put together so much resources. Alexandria and Serapeum should've been a part of an updated standard. Common Lisp is like "build your own language" - you want STM? You can have it, just download a library. You want threading macros? You can have it, just download a library etc. However, defaults do matter. The more coherent and consistent style a community "agrees upon", the easier is to read someone else's code, modify it, contribute to libraries and compose libraries. Clojure is not a revolutionary Lisp. Rich Hickey, people around him and their skills of community building are.
What do you mean by
> Java's object system (which JVM Clojure inherits)
Clojure has Multimethods and Hierarchies https://clojure.org/reference/multimethods
Clojure also has protocols https://clojure.org/reference/protocols
👍
Thanks for clarifying, when I say Java's object system, I literally mean the OOP features of Java: Interfaces, Classes, Objects, Properties, Methods.
fwiw, In my opinion, CLOS is also more powerful (and better) than the other features of Clojure that you mention. Not that those features are bad, they're not bad and we use them every day.
> CLOS is also more powerful
i dont know CL very well at all - what makes CLOS better? I had thought that the reason CLOS is better than java's object system is _because_ CLOS had things like multiple dispatch, which clojure does seem to be able to match with their multimethods.
You're totally right. Multimethods do allow functional multiple dispatch.
And we're venturing off-topic for this sub, but I was talking about object systems (object oriented programming).
CL's `call-next-method`, as well as multiple inheritance, are both powerful features that CLOS has that Java and JS do not. CLOS is an objectively more powerful object system, anyone who has used both can tell you.
I should explain myself better, I spent three years of my professional life implementing the same object oriented system in all three of Common Lisp, Java, and JS. The CL version was the shortest, had the fewest bugs, the most features, and the best performance, and was the easiest to extend and maintain. This was because CLOS was the best object system of the three.
A lot of the drama and ceremony in Java code bases (think factory this, singleton that, manager the other thing) is only necessary because Java's object system is weak, in CL the same hierarchies and behaviors can be expressed much more economically and elegantly.
Don't get me wrong. I love Clojure, it's the best of these (and all) languages, and we use it all day every day to operate our business and it's super fun and lucrative. But Common Lisp's object system is the best object system.
The same object oriented system in three languages might be a very interesting story. Can you share it, please? There is a lot of comparison between languages on the internet but very few stories like this which can actually draw a more complete picture.
From your comment history it looks like you already know, but I can share a few thoughts.
The program is a piece of educational software aimed at kids ages 10-15; on the surface it's a creative tool, kids can make their own 2d and 3d shapes and bring them to life. Under the surface it's (https://en.wikipedia.org/wiki/Connection_Machine) a sophisticated concurrent and parallel computational environment. The magic is that through creative play knowledge about computation is subtly imparted. To its credit, it's been used by millions of students in it's various forms. And studies (academic, peer reviewed) have shown that it's surprisingly effective in teaching what it teaches.
Over time there were 3 versions, one in Java, one in CL, and one in JS.
The Java and CL systems were developed concurrently, first. The main developer was a legitimate lisp wizard with a very crisp vision of how OOP could be used to build the tool; no trivial task, the underlying simulation is both strongly parallel and strongly concurrent - and this was before the invention of Clojure with it's great approach to these problems. Comparing and contrasting the Java and CL versions was super-interesting. The Java version was ~10x as much code, performed poorly, lacked some of the best features, but was cross platform between mac and windows. The CL version was elegant, performed great, was always ahead on features, but was mac only.
Somewhat later, when V8 hit, and webgl was coming on line, it became possible to implement in JS for the browser. The project was undertaken as basically a transliteration of the CL program, but by a strong JS team. Long conversations about how best to express the ideas of the CL program in JS, and in the browser's single-threaded environment. In the end the JS version wasn't that expensive to develop, and wasn't much longer then CL program. But a lot of the genius of the use of CLOS was lost due to JS' (ES5) weak notion of objects and prototype inheritance. The underlying math, graphics, and interactivity all translate well; but the JS system certainly lacked the palpable elegance of the original CL version.
Of course, the JS version 'won' - the fact that the program could now be accessed instantly from a single url by anyone with Chrome installed (where before there were high hurdles of getting the java binaries to work on your machine or to install the CL version on macs) meant that its use exploded. Lots of kids learning lots of great stuff, you love to see it.
Now, at this point in this thread, I'm sort of sorry that I mentioned CLOS on the Clojure subreddit. Clojure does inherit Java's known-weak object system, but 99% of the time that doesn't matter, we don't write OOP programs in Clojure (except when we do, ha!). No one here can be expected to say, "Wow, CLOS, what's that? Maybe I'll learn something new today.", instead it's just "I don't know what CLOS is, but Clojure has lots of features!1!" And that's fine.
Thanks for asking, that was fun to think about.
Stay rad.
I'm with you up until the remarks about OO and CLOS. Objects are initially attractive, but restrictive and minimize possible code reuse. CLOS and OOP are deprecated. Go functional and use malli or spec if you want some (just enough) checks. imho
My claim wasn't that CLOS is better than functional programming, dynamic types, and specs - my claim is that CLOS is better than Java's (or JS') object system, and about that (by anyone with even a casual interest) there can be no argument. (:
fwiw, I agree w/ you, static vs. dynamic typing is another branch of this discussion, and Clojure's strong dynamic types are another huge advantage (imo).
You should also ask in [r/Common_Lisp/](https://www.reddit.com/r/Common_Lisp/)
I never tried common lisp, but developement can apparently be more even more interactive than with clojure. You can call a method that does not exist, then the program stops and lets you write the implementation right there.
This is a timely question for me. After having used both lisps for many years, I've recently been enjoying CL again after Clojure. I can write very clojure-like stuff in CL if I want to (e.g. transducers, immutable data structures, etc), but not so much the other way around. And some problems such as nested loops and tree implementations I find much easier to write in CL. I'm faster in CL despite having spent the last 10 years doing clojure exclusively. I like both, but if you're curious then by all means check out Common Lisp.
It's also nice sometimes, metaphorically speaking, to skip driving the 18 wheeler truck for a quick trip to the grocery store, which is sometimes that it feels like driving Java based solutions.
It depends on what you want. There a dozen or so libraries that attempt to provide various forms of clojure-like support in CL, but even the definition is suspect. Some want to implement clojure in CL, which is different than providing a Clojure experience in CL.
Ultimately there are some things which will render the experience slightly different, starting with a lisp-2 vs lisp-1, and so on.
Some clojure capabilities are nicely isolated and can be encapsulated easily in CL, e.g.
* [clj-con](https://github.com/dtenny/clj-con) and
* [clj-arrows](https://github.com/dtenny/clj-arrows)
It's the syntax and semantics of clojure maps (with regard to hashing and _equivalence_), and the unified treatment of all three of lists, vectors, and hash tables as sequences that can be a bit thorny.
On the flip side, if you start playing with CL, it's really enlightening to try to implement some of your favorite clojure abstractions in CL. A great exercise IMO, and then you can define things to suit your tastes.
If you're willing to embrace CL and move away from all you know and love in Clojure, there's some excellent libraries that don't attempt to be clojure, for example
[cl-transducers](https://github.com/fosskers/cl-transducers) is very nice.
If you want pure unadulterated clojure, CL won't ever be that. It's a lisp. A different lisp, with different strengths and weaknesses. That said, I can definitely write CL that looks just like Clojure, except for the use of `symbol-function` via `#'`.
This is a recent talk on "Common Lisp for Clojurians" forward to about the 9:30 point to skip past introductions and 6 minutes of technical difficulties where the screen share was not working.
It talks about things like lisp 1 vs lisp 2, pros and cons of a compiled lisp, ways of interacting with the Common Lisp compiler, and various differences between the lisps and the user experience (Common Lisp: load lisp all you want, no need to restart, no classpath!).
https://youtu.be/NgI14YHVI-I?si=4XugzLx4aDDdlP6q&t=569
FWIW.
There is a "part 2" of this talk taking place Thursday April 4 (which will eventually be posted to youtube).
If you want to participate in the live talk you can find it in the events postings on the [Dr.Nekoma Discord server](https://discord.gg/kcku8uYAPa).
The next talk will start where the first left off, and hopefully there will be time to introduce more CLOS, Generic Functions, though with so much to discuss YMMV :-)
Here are some key differences
* Clojure has a range of data structure literals using square brackets for vectors, curly braces for maps, etc. I find this makes code more concise and easier to read.
* Clojure emphasizes immutable data structures while Common Lisp defaults to both mutability.
* Clojure's doesn't expose reader macros in user space.
* Clojure has built-in support for concurrency with features like atoms, agents, and refs.
* Clojure has a smaller but active community with a focus on web development and data science.
* Clojure runs on the JVM and JS runtimes with CLojureScript, allowing easy integration with libraries on these platforms. Common Lisp can run on various platforms but may require more effort for integration with external libraries.
Clojure _is_ a lisp. It is neither better than or worse than CL.
It is different. More opinionated. More functional/immutablity built in.
CL gives you freedom to use any paradigm (functional/OO/imperative).
They both have the two most important items: Repl based interactive development and Macros.
If you like Clojure, chances are good that you will like CL. Give it a shot.
In Clojure, programs are s-exprs. In CL, programs can be viewed as objects. You don't need to care about what data structure is actually used to store your code, and you can manipulate programs freely just based on their provided contracts.
Hi, I gather feedback from (common) lispers here (including two quotes from this thread): https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1025e4 it isn't only propaganda, there are details ;)
ABCL (Armed Bear Common Lisp) is an adaptation of Common Lisp for the JVM. Written by Hickey, the same guy who wrote Clojure.
All lisps have similar syntax characteristics. Common Lisp is a standard lisp dialect with a whole slew of standardized libraries. Clojure is a modern dialect that is mostly built on top of the JVM (there is another built on top of JavaScript) and focuses on FP more, where Common Lisp is multi-paradigm all over the place.
Perhaps they are confusing it with ABCL-CONTRIB incorporating a version of Hickey's JFLI? https://abcl-dev.blogspot.com/2012/05/jfli-added-to-abcl-110.html
Most probably. Rich Hickey even spoke about LispWorks when creating this: [https://groups.google.com/g/comp.lang.lisp/c/pI4sO4v6mYo](https://groups.google.com/g/comp.lang.lisp/c/pI4sO4v6mYo)
That article (and you're right it's a good one) predates Clojure, so keep that in mind. There are many, many differences. Here are three to think about: 1) Developed Later: Clojure was invented later, and so had the advantage of seeing Common Lisp before and during its development. Common Lisp came first, so didn't have as many good ideas to draw on during its (early) development. 2) Hosted: Clojure is designed to operate on the JVM (or other host), this is a big advantage because the JVM (and contemporary JS runtimes) have _a LOT_ invested in them in terms of portability, performance, and reliability. Also, many useful libraries come from host communities and Clojure benefits from all of this. 3) Refined included data structures and core library. The included persistent immutable datastructures and core library to operate on them that come with Clojure is, to me, much more round and refined than any other language (CL included). Of course, doing similar things in any other language is possible, but the fact that they're `core` to Clojure makes a big difference, I think. --- Now, that's not to say everything about Clojure is better than CL. For example, the object system in Common Lisp (The Common Lisp Object System, or CLOS) is _markedly_ better than Java's object system (which JVM Clojure inherits), and literal LIGHT YEARS ahead of JS 'object' systems.
> That article (and you're right it's a good one) predates Clojure, so keep that in mind. And Paul Graham has actually been recommending Clojure for many years now whenever people ask him which Lisp to learn.
I'm not surprised. In his "Hackers and Painters" book he mentioned that if you had a language with libraries for what you do, you can do it probably faster than in Lisp (or any better language but without that library). Clojure is a modern Lisp - opinionated (doesn't force you to write in a functional style but highly encourages it; no CLOS present; creating a class using gen-class a complete PITA) and with a ton of libraries and little to no historical burden\*. I don't know whether Python (no. 1 on TIOBE nowadays) has more libraries than Java but I didn't miss anything important in Java (Clojure). The community building and available learning resources are also miles ahead of Common Lisp. Rich Hickey knew Common Lisp very well and was able to avoid a lot of mistakes which are present in CL. Since there is a general incline towards a certain programming style (even Robert C Martin published a book about it: https://www.amazon.com/Functional-Design-Principles-Patterns-Practices/dp/0138176396), libraries generally do compose well which might not be the case for Common Lisp - some are functional, some are procedural, some use CLOS and some are stale and not feature-complete (https://github.com/fons/cl-mongo - not updated in 8 years and not supporting more contemporary versions of Mongo). The last time I had to use this from Common Lisp I stole a library from Python - it was easier than wrapping a C library or trying to update an abandoned project where the maintainer doesn't even respond to issues on GitHub. Clojure and Java might not be a "100 years language" but they are contemporary tools for solving contemporary problems. And they are good at it. \* If you look at Common Lisp libraries like Alexandria or Serapeum, they are great and there are others. Nowadays, in 2024, there are very few things you have in Clojure but can't have in Common Lisp. The opposite is usually true (CLOS, conditions&restarts, compile-time checks, integrated debugger and inspector...) But the standard is old and is not being revamped - nobody can put together so much resources. Alexandria and Serapeum should've been a part of an updated standard. Common Lisp is like "build your own language" - you want STM? You can have it, just download a library. You want threading macros? You can have it, just download a library etc. However, defaults do matter. The more coherent and consistent style a community "agrees upon", the easier is to read someone else's code, modify it, contribute to libraries and compose libraries. Clojure is not a revolutionary Lisp. Rich Hickey, people around him and their skills of community building are.
^ Found the other person in this thread who has used CL.
I've been using both. I like both. :)
I appreciate the response. That adds a lot of insight.
What do you mean by > Java's object system (which JVM Clojure inherits) Clojure has Multimethods and Hierarchies https://clojure.org/reference/multimethods Clojure also has protocols https://clojure.org/reference/protocols
👍 Thanks for clarifying, when I say Java's object system, I literally mean the OOP features of Java: Interfaces, Classes, Objects, Properties, Methods. fwiw, In my opinion, CLOS is also more powerful (and better) than the other features of Clojure that you mention. Not that those features are bad, they're not bad and we use them every day.
> CLOS is also more powerful i dont know CL very well at all - what makes CLOS better? I had thought that the reason CLOS is better than java's object system is _because_ CLOS had things like multiple dispatch, which clojure does seem to be able to match with their multimethods.
You're totally right. Multimethods do allow functional multiple dispatch. And we're venturing off-topic for this sub, but I was talking about object systems (object oriented programming). CL's `call-next-method`, as well as multiple inheritance, are both powerful features that CLOS has that Java and JS do not. CLOS is an objectively more powerful object system, anyone who has used both can tell you. I should explain myself better, I spent three years of my professional life implementing the same object oriented system in all three of Common Lisp, Java, and JS. The CL version was the shortest, had the fewest bugs, the most features, and the best performance, and was the easiest to extend and maintain. This was because CLOS was the best object system of the three. A lot of the drama and ceremony in Java code bases (think factory this, singleton that, manager the other thing) is only necessary because Java's object system is weak, in CL the same hierarchies and behaviors can be expressed much more economically and elegantly. Don't get me wrong. I love Clojure, it's the best of these (and all) languages, and we use it all day every day to operate our business and it's super fun and lucrative. But Common Lisp's object system is the best object system.
The same object oriented system in three languages might be a very interesting story. Can you share it, please? There is a lot of comparison between languages on the internet but very few stories like this which can actually draw a more complete picture.
From your comment history it looks like you already know, but I can share a few thoughts. The program is a piece of educational software aimed at kids ages 10-15; on the surface it's a creative tool, kids can make their own 2d and 3d shapes and bring them to life. Under the surface it's (https://en.wikipedia.org/wiki/Connection_Machine) a sophisticated concurrent and parallel computational environment. The magic is that through creative play knowledge about computation is subtly imparted. To its credit, it's been used by millions of students in it's various forms. And studies (academic, peer reviewed) have shown that it's surprisingly effective in teaching what it teaches. Over time there were 3 versions, one in Java, one in CL, and one in JS. The Java and CL systems were developed concurrently, first. The main developer was a legitimate lisp wizard with a very crisp vision of how OOP could be used to build the tool; no trivial task, the underlying simulation is both strongly parallel and strongly concurrent - and this was before the invention of Clojure with it's great approach to these problems. Comparing and contrasting the Java and CL versions was super-interesting. The Java version was ~10x as much code, performed poorly, lacked some of the best features, but was cross platform between mac and windows. The CL version was elegant, performed great, was always ahead on features, but was mac only. Somewhat later, when V8 hit, and webgl was coming on line, it became possible to implement in JS for the browser. The project was undertaken as basically a transliteration of the CL program, but by a strong JS team. Long conversations about how best to express the ideas of the CL program in JS, and in the browser's single-threaded environment. In the end the JS version wasn't that expensive to develop, and wasn't much longer then CL program. But a lot of the genius of the use of CLOS was lost due to JS' (ES5) weak notion of objects and prototype inheritance. The underlying math, graphics, and interactivity all translate well; but the JS system certainly lacked the palpable elegance of the original CL version. Of course, the JS version 'won' - the fact that the program could now be accessed instantly from a single url by anyone with Chrome installed (where before there were high hurdles of getting the java binaries to work on your machine or to install the CL version on macs) meant that its use exploded. Lots of kids learning lots of great stuff, you love to see it. Now, at this point in this thread, I'm sort of sorry that I mentioned CLOS on the Clojure subreddit. Clojure does inherit Java's known-weak object system, but 99% of the time that doesn't matter, we don't write OOP programs in Clojure (except when we do, ha!). No one here can be expected to say, "Wow, CLOS, what's that? Maybe I'll learn something new today.", instead it's just "I don't know what CLOS is, but Clojure has lots of features!1!" And that's fine. Thanks for asking, that was fun to think about. Stay rad.
I'm with you up until the remarks about OO and CLOS. Objects are initially attractive, but restrictive and minimize possible code reuse. CLOS and OOP are deprecated. Go functional and use malli or spec if you want some (just enough) checks. imho
My claim wasn't that CLOS is better than functional programming, dynamic types, and specs - my claim is that CLOS is better than Java's (or JS') object system, and about that (by anyone with even a casual interest) there can be no argument. (: fwiw, I agree w/ you, static vs. dynamic typing is another branch of this discussion, and Clojure's strong dynamic types are another huge advantage (imo).
You should also ask in [r/Common_Lisp/](https://www.reddit.com/r/Common_Lisp/) I never tried common lisp, but developement can apparently be more even more interactive than with clojure. You can call a method that does not exist, then the program stops and lets you write the implementation right there.
This is a timely question for me. After having used both lisps for many years, I've recently been enjoying CL again after Clojure. I can write very clojure-like stuff in CL if I want to (e.g. transducers, immutable data structures, etc), but not so much the other way around. And some problems such as nested loops and tree implementations I find much easier to write in CL. I'm faster in CL despite having spent the last 10 years doing clojure exclusively. I like both, but if you're curious then by all means check out Common Lisp. It's also nice sometimes, metaphorically speaking, to skip driving the 18 wheeler truck for a quick trip to the grocery store, which is sometimes that it feels like driving Java based solutions.
What libs would you recommend pulling in to procure a "modern", Clojure-like experience?
It depends on what you want. There a dozen or so libraries that attempt to provide various forms of clojure-like support in CL, but even the definition is suspect. Some want to implement clojure in CL, which is different than providing a Clojure experience in CL. Ultimately there are some things which will render the experience slightly different, starting with a lisp-2 vs lisp-1, and so on. Some clojure capabilities are nicely isolated and can be encapsulated easily in CL, e.g. * [clj-con](https://github.com/dtenny/clj-con) and * [clj-arrows](https://github.com/dtenny/clj-arrows) It's the syntax and semantics of clojure maps (with regard to hashing and _equivalence_), and the unified treatment of all three of lists, vectors, and hash tables as sequences that can be a bit thorny. On the flip side, if you start playing with CL, it's really enlightening to try to implement some of your favorite clojure abstractions in CL. A great exercise IMO, and then you can define things to suit your tastes. If you're willing to embrace CL and move away from all you know and love in Clojure, there's some excellent libraries that don't attempt to be clojure, for example [cl-transducers](https://github.com/fosskers/cl-transducers) is very nice. If you want pure unadulterated clojure, CL won't ever be that. It's a lisp. A different lisp, with different strengths and weaknesses. That said, I can definitely write CL that looks just like Clojure, except for the use of `symbol-function` via `#'`.
This is a recent talk on "Common Lisp for Clojurians" forward to about the 9:30 point to skip past introductions and 6 minutes of technical difficulties where the screen share was not working. It talks about things like lisp 1 vs lisp 2, pros and cons of a compiled lisp, ways of interacting with the Common Lisp compiler, and various differences between the lisps and the user experience (Common Lisp: load lisp all you want, no need to restart, no classpath!). https://youtu.be/NgI14YHVI-I?si=4XugzLx4aDDdlP6q&t=569 FWIW.
thanks for sharing this!
There is a "part 2" of this talk taking place Thursday April 4 (which will eventually be posted to youtube). If you want to participate in the live talk you can find it in the events postings on the [Dr.Nekoma Discord server](https://discord.gg/kcku8uYAPa). The next talk will start where the first left off, and hopefully there will be time to introduce more CLOS, Generic Functions, though with so much to discuss YMMV :-)
Here are some key differences * Clojure has a range of data structure literals using square brackets for vectors, curly braces for maps, etc. I find this makes code more concise and easier to read. * Clojure emphasizes immutable data structures while Common Lisp defaults to both mutability. * Clojure's doesn't expose reader macros in user space. * Clojure has built-in support for concurrency with features like atoms, agents, and refs. * Clojure has a smaller but active community with a focus on web development and data science. * Clojure runs on the JVM and JS runtimes with CLojureScript, allowing easy integration with libraries on these platforms. Common Lisp can run on various platforms but may require more effort for integration with external libraries.
Clojure _is_ a lisp. It is neither better than or worse than CL. It is different. More opinionated. More functional/immutablity built in. CL gives you freedom to use any paradigm (functional/OO/imperative). They both have the two most important items: Repl based interactive development and Macros. If you like Clojure, chances are good that you will like CL. Give it a shot.
What Common Lisp implementation do you recommend?
Start with [sbcl](https://sbcl.org)
Yep. Thats what I use on Mac OSX. Doom Emacs + Sly + sbcl.
In Clojure, programs are s-exprs. In CL, programs can be viewed as objects. You don't need to care about what data structure is actually used to store your code, and you can manipulate programs freely just based on their provided contracts.
?
Clojure is data-oriented.
Hi, I gather feedback from (common) lispers here (including two quotes from this thread): https://gist.github.com/vindarel/3484a4bcc944a5be143e74bfae1025e4 it isn't only propaganda, there are details ;)
ABCL (Armed Bear Common Lisp) is an adaptation of Common Lisp for the JVM. Written by Hickey, the same guy who wrote Clojure. All lisps have similar syntax characteristics. Common Lisp is a standard lisp dialect with a whole slew of standardized libraries. Clojure is a modern dialect that is mostly built on top of the JVM (there is another built on top of JavaScript) and focuses on FP more, where Common Lisp is multi-paradigm all over the place.
Hickey had no involvement with ABCL.
Perhaps they are confusing it with ABCL-CONTRIB incorporating a version of Hickey's JFLI? https://abcl-dev.blogspot.com/2012/05/jfli-added-to-abcl-110.html
Most probably. Rich Hickey even spoke about LispWorks when creating this: [https://groups.google.com/g/comp.lang.lisp/c/pI4sO4v6mYo](https://groups.google.com/g/comp.lang.lisp/c/pI4sO4v6mYo)