[HN Gopher] Lisp: Notes on its Past and Future (1980)
___________________________________________________________________
Lisp: Notes on its Past and Future (1980)
Author : birdculture
Score : 64 points
Date : 2025-11-02 19:05 UTC (3 hours ago)
(HTM) web link (www-formal.stanford.edu)
(TXT) w3m dump (www-formal.stanford.edu)
| labrador wrote:
| 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.
| armitron wrote:
| 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.
| lenkite wrote:
| > the JVM, which looks more dead with every passing year.
|
| Lol, only dying/dead in the febrile imagination of some HN
| commenters. The JVM has had some of the most explosive
| feature activity in the last several years. Java had several
| million greenfield projects in 2024-25 - among the top 6
| greenfield programming languages according to the Github
| Octoverse.
| kleiba wrote:
| But also: https://survey.stackoverflow.co/2024/work#3-salary-
| and-exper...
| kragen wrote:
| Prolog and Dart programmers earn the least, but Erlang and
| Clojure programmers earn the most? Something is fishy
| here...
| kleiba wrote:
| I would take this statistics, like every other one, with
| a grain of salt, but still wanted to put it out there as
| a possible discussion point.
| cmrdporcupine wrote:
| Likely just not a statistically significant enough sample
| of any of those to justify them even putting them on the
| chart. Except maybe Dart, and that gets the "curse" of
| being front-end tech which for some inexplicable reason
| is underpaid.
| lycopodiopsida wrote:
| 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.
| mpenet wrote:
| 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.
| bitwize wrote:
| 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.
| gleenn wrote:
| Which makes Clojure extra tempting because there is a bit
| of a infectious way to get Clojure i to corporations when
| you are always just handing the ops guys a "Java" we app
| bundled as a jar but secretly inside it's all Clojure
| compiled classfiles that work perfectly run on many JVM-
| based web servers with no additional effort.
|
| I think Rich even alludes to this fact in one of his talks
| where it would be disallowed to run Ruby/Python/Rust
| whatever but it's Java then it's a know entity.
| kloud wrote:
| 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.
|
| [0] https://github.com/jank-lang/clojure-test-suite
| cmrdporcupine wrote:
| 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? :-)
| labrador wrote:
| I don't care if it's niche if it solves my problems and gets
| the job done faster.
| chamomeal wrote:
| 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
| AnimalMuppet wrote:
| You're saying that Clojure is looking more dead, so you
| suggest... _Common Lisp_? That looks considerably more dead
| than Clojure.
| lucasoshiro wrote:
| > 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)
| labrador wrote:
| 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.
| bmitc wrote:
| I would argue that F# would be the choice of language in
| place of Rust if you don't want to deal with Rust's type
| system. F# is immutable by default with good concurrency
| and a static type system.
| labrador wrote:
| That's a great suggestion I had forgotten about, which is
| strange since I'm a C# programmer. Part of me wants to
| really learn a Lisp to see what it is special about it
| that I keep hearing about. I tried Racket and Steel Bank
| Common Lisp but they didn't seem appropriate for the
| commercial programming I'm used to. Clojure is being used
| commercially.
| bmitc wrote:
| I also really like Lisps/Schemes. I've always wanted to
| pick up Clojure but don't like how it thinly sits on top
| of the JVM compared to F# being deeply integrated. I
| always had trouble getting Clojure properly installed
| compared to just downloading .NET and having F# or easily
| downloading Racket.
|
| You should absolutely try out F#. :) It's a great
| language.
|
| Also, if you're looking for the magic of Lisp/Scheme, I
| think you might really enjoy Elixir/Erlang. Elixir has
| macros, has purely immutable data (there is _no_ way
| whatsoever to get mutable data unlike F#, Racket,
| Clojure, etc.), live code updates, and the BEAM VM, its
| process framework, and OTP are quite magical.
|
| When I first learned Erlang, I felt I had come home. I
| mainly used Elixir though due to the available packages
| and jobs.
| Zambyte wrote:
| 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.
| kloud wrote:
| > 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.
| goatlover wrote:
| 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.
| mmmm2 wrote:
| LLMs seem better suited to help with the Tower of Babel we've
| created for ourselves: aws commands, Terraform modules, Java
| libraries, Javascript/React, obscure shell commands, etc.
| atgreen wrote:
| I've been having a great time generating Common Lisp code
| with LLMs. eg. https://github.com/atgreen/cl-tuition ,
| https://github.com/atgreen/ctfg , etc.
| seg_lol wrote:
| Pull request incoming to add back your missing README
| emojis.
| kloud wrote:
| The strength of Lisps is in ability to define DSLs and then
| concisely express solutions for problems in that domain.
| Arguably no other programming language was able to exceed or
| even match that power until now.
|
| The math behind transformers is deterministic, so LLMs could
| be treated as compilers (putting aside intentionally adding
| temperature and non-determinism due to current internal GPU
| scheduling). In the future I imagine we could be able to
| declare a dependency on a model, hash its weights in a
| lockfile and the prompt/spec itself will be the code, which
| corresponds to that insight.
| labrador wrote:
| 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
| bmitc wrote:
| 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.
| AnimalMuppet wrote:
| > 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.
| sema4hacker wrote:
| 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.
| shawn_w wrote:
| Common Lisp supports both styles. Shoot, it probably favors
| procedural over functional a bit.
| PessimalDecimal wrote:
| 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 with 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.
___________________________________________________________________
(page generated 2025-11-02 23:00 UTC)