Lisp: Notes on its Past and Future (1980)

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.

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.

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

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.

But also: https://survey.stackoverflow.co/2024/work#3-salary-and-exper...

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.

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 don't care if it's niche if it solves my problems and gets the job done faster.

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? :-)

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.

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.

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.

JavaScript has been called "Lisp in C's clothing". JavaScript is not a "pure" functional language but are any of the Lisps either? They might have immutability as the default. But I don't see why an Object-Oriented language could not have immutability as the default as well?

In the 80's Lisp was already over 20 years old.

From what I've understood about Haskell is that it allows you to divide your program into parts which are either pure functional, or mutable. That is great when you read the program, you can know that what you are reading now is immutable, whereas in the some other well designated parts it is mutable.

But with Lisps isn't it the case that statement 1 can be immutable while the next statement 2 is mutable? In other words it mixes mutable and immutable calls into the same program-file without really isolating them from each other in any way. And that means if one part of the program is "impure", so is all of it. You can't isolate those parts except by following a convention, but conventions are not something that it enforces. And you can't know which parts of your program are pure except by reading the code-statements in detail. Am I right?

It supports basically all styles which makes it wonderfully useful in whatever domain you happen to find yourself in.