Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • 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.
  • 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.
  • 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.
  • 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.

  • Common Lisp supports both styles. Shoot, it probably favors procedural over functional a bit.
  • 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

  • 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?
  • 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.

  • 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.

  • 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.

    https://github.com/jank-lang/jank

  • It’s cool how people keep finding new joy in old ideas like Lisp. Shows that good design never really dies.
  • > 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.

  • 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
  • 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.

  • > 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.

  • 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.

  • 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 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.

  • Clojure seems to be pretty strong. At least here in Brazil, several companies here use it as their main programming language
  • > 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!

  • Lisp has disadvantages too. I wrote about some of them in https://paulgraham.com/redund.html.
  • 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.
  • How does Clojure do on McCarthy's desiderata from this paper, as you see it?
  • 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.

  • 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.
  • 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!

  • > 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 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.

  • 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.