▲ 193 points
back
105 comments
Old Lisp posts are cool, then if you want a refresher of what's happening in the CL ecosystem (tools, libraries, compilers…) here's an overview of the last two years (shameless plug): https://lisp-journey.gitlab.io/blog/these-years-in-common-li... and very cool new projects appeared in 2025.
It occurred to me this morning that I should learn Clojure instead of Rust for non-lowlevel code because Clojure solves the same problems Rust solves in a much simpler way. I'm a fan of Clojure author Rich Hickey's "Simple Made Easy" talk but otherwise don't know either language in detail and need to do more research.
The Clojure (or any Lisp) journey is very different, not because of the language per se, but because of the developer experience.
In Clojure, there's no appreciable compilation time. During my work week I barely, if ever, restart the application I'm working on: I'm working inside of it via a REPL connection.
It's an entirely different ball game and if you just compare language features you are missing out on an incredible interactive coding experience.
Does it scroll? Because I like to scroll around when thinking about my program. I always imagine Lips REPL ppl saying they keep the entire program in their head but that can't be right. That's doing things the hard way.
Can confirm! Once I started doing this (now mainly with iPython interactive in VSCode) my output speed increased dramatically
To note that the same experience is shared with Smalltalk, and modern IDEs still are lacking of both.
> Clojure solves the same problems Rust solves in a much simpler way
I'm curious about that, can you elaborate? I'm a beginner in Clojure and I only know a few concepts about Rust, but it seems to me that they solve (at least, currently) very different problems...
I only saw Rust being used in places where C or C++ would be used in the past (Linux kernel, CLI apps, desktop apps), while I only saw Clojure being used as a modern and functional Java and JS replacement.
Not to mention how different they are as languages (static vs dynamic typing, native vs jvm, borrow checker vs garbage collection)
The main problem that Rust tries to solve, and that functional programming (which Clojure heavily leans into) solves, is avoiding shared mutable state, which leads to data races and (potentially subtly) wrong concurrent programs. Functional programming avoids shared mutable state by avoiding mutable state. Operations are only represented as transformations instead of mutations. Other languages like Erlang / Elixir use message passing techniques like the Actor Model to avoid shared mutability. Instead of avoiding mutability, like in functional programming, in the Actor Model you avoid sharing, by instead sending messages around.
Rust is interesting because it solves the problem of shared mutable state, while allowing sharing, and allowing mutability, just not at the same time. State can be mutated until it is shared. While it is shared, it cannot be mutated. This is the goal of the ownership system in Rust.
One thing that jumped out at me is you don't need Rust's borrow checker to prevent thread race conditions because data in Clojure is immutable. That's a huge simplification over Rust. What I hear mostly about Rust is complaints about the borrow checker. I wrote a simple Rust utility and found it frustrating. But again, don't take my word for it because I don't know either language.
This the “non-low level” code qualification.
As an anecdote, about a year ago I realized I was not having that much fun learning rust. Randomly landed on clojure instead and have absolutely loved it.
Particularly as a noob, babashka is SUCH a good way to learn the language. I’ve written myself all sorts of fun utilities with babashka and have learned so much clojure along the way. Even got my coworkers to use my bb scripts!
I would recommend taking a look at some of the schemes. In particular I've been having tons of fun with CHICKEN: https://call-cc.org/ - the fact that it compiles to C and can generate binaries is a great plus.
I have been enjoying Chez scheme these last few weeks, and having an LLM has helped me when i have missing libraries. The ability to just wrap a C library and statically link everything into a single binary has been really nice too!
Clojure is a niche language that (for realistic purposes) is still tied to a single platform, the JVM, which (Clojure, not the JVM) looks more dead with every passing year. It never became popular and it's been steadily losing users. It's also not as general purpose as Common Lisp (ie. not suited for system or lowlevel programming).
If you're going to learn a niche Lisp, you might as well learn Common Lisp or Scheme which have well-specified standards, have stood the test of time and will still be around for decades to come.
Although niche, things are pretty lively in the community. Among other things this year great progress was made on Jank, the native LLVM-based implementation with seamless low-level C++ interop. As part of that work a test suite is being created [0] and now includes runners for all of the major implementations to compare compatibility, next best thing besides a formal specification.
Clojure will be around as long as the jvm. It’s mostly done at the core level, most updates are to leverage new host features nowadays. The rest is happily provided at the library level by the community (which is still very prolific).
And it’s not tied to the jvm per say, look at clojurescript (and derivatives) or the upcoming jank.
It’s far from dead. As much as I like CL, the ecosystem is a bit of a desert compared to the jvm.
The JVM has suffered a fate worse than death: it's become so wildly successful that it's boring. So much enterprise shit runs on Java that it has sort of faded into the background noise of civilization and, like the System/360 (now Z/OS) before it, doesn't grab headlines anymore.
JVM is very much not dead even slightly. They just released virtual threads, which are ridiculously awesome. Also it's not tied to a single platform, clojurescript lets you write clojure in browsers and on node.js, and babashka lets you use clojure in a scripting environment via a single executable
I frankly miss the JVM. I work almost exclusively in Rust these days and haven't worked in Java or Scala since 15 years ago, and I do prefer working closer to the metal.... But... The JVM is an amazing mature runtime with a boatload of tooling. JMX, which has been there since almost the beginning, is the kind of thing missing from almost everything other managed runtime I've worked with.
The amount of R&D that has gone into making it execute with good performance, and its overall stability...
Yeah, it's got the curse of being boring.
I do think it is perhaps unfortunate that Clojure is tied so heavily to the JVM, because I actually don't think it gains much from that ecosystem... but it's a product of the time it was first written.
Actually hell. I'm between jobs, I like Lisp, and I miss the JVM. I've never worked in Clojure, but does anybody want to hire me to work in it? :-)
I prefer CL, but… clojure at least has some commercial usage and is by far the most successful of current lisps, if we do not count elisp.
Clojure is not going anywhere anytime soon.
It sees plenty use as Clojure/Clojurescript and Babashka. (and other niche variants). Jank is shaping up to be real nice too.
I don't care if it's niche if it solves my problems and gets the job done faster.
You're saying that Clojure is looking more dead, so you suggest... Common Lisp? That looks considerably more dead than Clojure.
How does Clojure do on McCarthy's desiderata from this paper, as you see it?
I'm curious why Lisp didn't gain mass popularity despite its advantages. In fact, I was wondering if it's popularity has event decreased in the past decade or so. I remember in the 2000s and even early 2010s, there were active discussion on Clojure, Scheme, and functional/logic programming in general. There seems much less discussion or usage nowadays. One theory is that popular languages have absorbed many features of functional programming, so the mainstream programmers do not feel the need to switch. My pet theory is that many of us mortals get the productivity boost from the ecosystem, in particular powerful libraries and frameworks. Given that, the amazing features of lisp, such as its s-expression, may not be powerful enough to sway users to switch.
Lisp has disadvantages too. I wrote about some of them in https://paulgraham.com/redund.html.
> I'm curious why Lisp didn't gain mass popularity despite its advantages.
In my opinion Lisp is too flexible. I think the ideal use of Lisp is one or a few talented developers exploring the problem space and creating the MVP. Then a follow on team to reimplement it in a mainstream language that’s more maintainable by “mere mortals”.
Ime it’s similar to the fact that projects implemented with statically typed languages are easier to maintain than dynamically typed languages. Lisp is so flexible even lexical scoping (of variables for example) is a choice. Not what I’d care to have juniors or run of the mill seniors responsible for!
Clojure seems to be pretty strong. At least here in Brazil, several companies here use it as their main programming language
Lisp was the first to have first-class functions and garbage collection which have become common language features by now. But it also has many features that still are not widespread. Its metaprogramming is unparalleled, especially reader macros. A lot of its power comes from that. Rust macros and C++26 compile time reflection are steps in the right direction but still nowhere near what Lisp offers. Java's Project Babylon is also cool but not in the same ballpark.
When doing joint debugging with teammates, I've seen so many of them randomly add or remove & and * from C++ statements trying to get their code to compile, without bothering to reason through the issue. I suspect this stochastic approach to code development is pretty common. That is not going to unlock the benefits of metaprogramming either, where you have to deliberately build up the language you want to have.
Metaprogramming is extremely powerful but hard to use, especially for novices. I also think there is a general lack of education about programming languages and compilers at play here. So much of Lisps power comes from knowing that.
> It seems to me that LISP will probably be superseded for many purposes by a language that does to LISP what LISP does to machine language. Namely it will be a higher level language than LISP that, like LISP and machine language, can refer to its own programs. (However, a higher level language than LISP might have such a large declarative component that its texts may not correspond to programs. If what replaces the interpreter is smart enough, then the text written by a user will be more like a declarative description of the facts about a goal and the means available for attaining it than a program per se).
Pretty accurate foresight in 1980, in the "Mysteries and other Matters" section McCarthy predicting declarative textual description replacing lisp as a higher-level programming language, basically describing todays LLMs and agentic coding.
I don't see the connection to LLMs. With LLMs, you have a highly non-deterministic system that is also highly probable to be incorrect.
It seems like a stretch to say that's what McCarthy was thinking about regarding declarative facts and goals driving a program.
> Pretty accurate foresight in 1980, in the "Mysteries and other Matters" section McCarthy predicting declarative textual description replacing lisp as a higher-level programming language, basically describing todays LLMs and agentic coding.
To me, that sounds more like Prolog than agentic coding.
How many people are using LLMs to replace coding in Lisp? What code are these former Lispers producing with LLM Agents?
I understand what you're trying to say, but I don't think LLMs were created as some replacement for Lisp. I don't think they've replaced any programming language, but they do help quite a bit with autogeneration of Python & Javascript in particular.
That is remarkable foresight. I've had Google Gemini take a Dart program it wrote for me and had it convert it to TypeScript while adding some additional requirements - so declarative programming and treating code as data
It’s cool how people keep finding new joy in old ideas like Lisp. Shows that good design never really dies.
We know in hindsight that lisp became most useful for representing computation, but what ever happened to AI? McCarthy says it's characteristic of LISP. SICP also mentions AI as being fundamental to lisp at the beginning of the book. Norvig & Russel used Common Lisp for the first edition of their book. But, then what happened? Why did it just disappear for no reason?
Lisp didn’t really disappear, symbolic AI did.
Lisp was ideal for reasoning systems, its homoiconic and meta-programmable nature is perfect for manipulating symbolic structures and logic. But when AI shifted toward numerical learning with neural networks, tensors, and GPU computation, Lisp’s strengths mattered less, and Python became the new glue for C/CUDA libraries like NumPy, PyTorch and TensorFlow.
Still, nothing prevents Lisp from coming back. It would actually fit modern deep learning well if a "LispTorch" with a CUDA FFI existed. We would have macros for dynamic graph generation, functional composition of layers, symbolic inspection, interactive REPL exploration, automatic model rewriting etc.
We almost had it once: Yann LeCun’s SN (the first CNN) was built on a C core with a Lisp interpreter on top to define, develop and inspect the network. It eventually evolved into Lush, essentially "Lisp for neural networks", which in turn inspired Torch and later PyTorch.
https://x.com/ylecun/status/1944504502260003296?lang=en
So Lisp didn't die in AI, it's just waiting for the right people to realize its potential for modern neural networks and bring it back. Jank in particular will probably be a good contender for a LispTorch.
The AI winter happened. And the AI they talk about is classical, symbolic AI where you try to explicitly represent knowledge inside the computer. The new LLM stuff is all neural networks, and those benefit more from fast low-level vector implementations than high-level ease of symbolic manipulation.
So modern AI is all mostly C or even Fortran, often driven from something more pedestrian, like Python.
I'm not sure what exactly you're referring to, but one avenue to implement AI is genetic programming, where programs are manipulated to reach a goal.
Lisp languages are great for these manipulations, since the AST being manipulated is the same data structure (a list) as everything else. In other words, genetic programming can lean into Lisp's "code is data" paradigm.
As others mentioned, today everything is based on neural networks, so people aren't learning these other techniques.
nice, I was hacking common lisp this weekend.
Also this video was interesting, Oral History of John McCarthy: https://www.youtube.com/watch?v=KuU82i3hi8c&t=1564s
I think when programmers are introduced to languages, most grok procedural ones easier than functional ones, hence Lisp and its derivatives have struggled in popularity for decades.
Common Lisp supports both styles. Shoot, it probably favors procedural over functional a bit.
I have been thinking about the reason why Lisps aren't more popular today. I'm not sure yours is the right reason though. It seems like the statement you make would be no more true today than in the 80s, when Lisp was much more popular.
Ultimately I think it might just be fads. Object oriented programming came along at the same time as the web, when the demand for programmers grew dramatically. That may have crystallized OO and imperative languages as the "default" style. Would be interesting to see the alternate universe where JavaScript actually was a Lisp.
Back in the 80s we had logo, that was super popular and a common way a lot of people (kids) learned programming, the birth of turtle graphics! That repl way of programming and getting visual results was really good. I think the biggest problem was that none of those languages were the languages for making games.
When I teach I constantly tell them to start with data and hard coded, literal data representations, this seems to make it rather easy to get used to a functional style.