The Future of Lisp

Another rescued Quora answer to the question : What is the future of the LISP programming language?

I’m writing this answer as an unabashed Clojure fanboi.

I hope that the Lisp community recognise what I think are the two big advantages that Clojure brings to Lisp. And that future Lisp family languages keep them and build on them.

The first of these advantages is immutability. Most FP languages go hard for immutability (it’s more or less the essence of FP). But for historical reasons Lisps have tried to sell themselves to a wider public on being “multi-paradigm” and so have been tolerant of mutable state.

I’m a fan of immutability though (Phil Jones (He / Him)'s answer to In your experience, are immutable data structures and paradigms easier or harder to understand in general (and especially for newcomers) than regular imperative mutable programming paradigms? Why?) and I hope very much that we’ll see both growth in Clojure. But also newer Lisps will follow its lead in restricting state to very specific mechanisms like “atoms” etc.

The second of these advantages is syntax for data-structures.

As I’ve mentioned elsewhere ( Phil Jones (He / Him)'s answer to If Clojure is one of the most expressive languages of today and has similar expressive power as Common Lisp, which goes back to early 80s, can we say that the field of programming languages hasn't progressed much in the last 40 years?) representing “computation” is a solved problem in programming languages. And Lisp’s minimal syntax is just fine for it. But there is scope for better representation of data. And I believe that Clojure’s EDN demonstrates that it is worth trading the cost of a little bit of extra syntax, in return for better ways to express complex data literals in our programs.

Today, for anyone thinking of inventing a new Lisp, I would strongly urge them to adopt both of these features from Clojure. Build the language on EDN with the vectors and maps and keywords standard along with the usual parentheses for list syntax. Implement these standard data structures as immutable. And restrict mutable state with specific mechanisms like atoms and refs.

Now, if you read that second answer linked above, about expressivity, you’ll know I have some further opinions about language design. And syntax for representing data, architecture and constraints.

I’m very ambivalent about static typing. I tend to be in the dynamic typing, not caring much for static types camp. With occasional visits to the “OMG I wish I had a way of setting and testing type constraints on this mess” camp.

Clojure has Spec. Which I think has both some good features. And some features I can’t get on with.

Two developments that interest me greatly are Shen Language and Carp Lang

Shen is a Lisp that adds a powerful type checker. One which is almost a kind of Prolog-like inference engine.

Carp is an interesting mix of Clojure syntax, but with low level memory management inspired by Rust (a borrow checker). And a type system with type inference that’s more like the ML family of languages than a Lisp. It has these features because it’s aimed at writing low-level code for embedded systems, games and audio applications etc.

But one thing that distinguishes it is that it has, what looks to me, the nicest, most Lispish and convenient way to add type checking I’ve seen in a Lisp. You wrap any expression with what’s effectively a compile time assert that the expression result is of a particular type.

So you write something like :

(defn f [x y] (the int (+ x y)))

That’s it. You’ve typed the expression (+ x y) as having to return an int. (That’s what (the int sexp) does. )

And then type inference lets that constraint percolate through. Eg. it recognises that the arguments x and y must be ints and the return value of the function will be one.

This feels right to me in a way that other optional / gradual type-checking in Lisp doesn’t. Maybe I just don’t get it, but Spec comes across as the opposite of Clojure’s usual elegance of beautiful design. It’s ugly and clunky.

There are definitely days I dream of “the next Clojure” (ie. the next step forward in Lisp) which is like Clojure except that Spec has become as powerful as Shen, and as elegantly easy to slot into existing code as Carp. With compile-time checking.)