Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples:

1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors, one of which is merged and open to beta testing. One of them is a parallel collector written by a university student (!!) which blows my mind.

2. SBCL has better and better support for deploying Lisp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python, without the baggage of process wrangling and thick RPC (IPC/servers, serialization, ...).

3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged [1], and interestingly, they're implemented purely in Coalton [2]. That means Clojure-like seqs.

It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc.

[1] https://coalton-lang.github.io/reference/#seq-type

[2] https://github.com/coalton-lang/coalton/blob/main/library/se...

> our planet and the technology we use. By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment.

Wait what?! When was the last time programmers chose a language because it was "green"? What does it even mean for a language to be "greener" than the others?

Is there a "Common Lisp Electron" thing floating around?

The GUI situation of the free lisps is pretty much a non-started for anything portable, just curious if there's a project bundling Common Lisp with a browser window, like Rust Taurus.

At this level, there's no reason to fret about download sizes anymore if you're comparing to something like Electron, so no real need to "shake the tree" or really limit the lisp image size. Modern lisps aren't that big compared to most anything else anyway.

Lisp Flavoured Erlang (lfe.io) needs more love, from what I’ve seen and tried with it - it could give clojure a run for its money.

Our TrinPod Server with conceptual AI and space-time digital twin is all in Common Lisp (and incredibly easy to work with and evolve): https://graphmetrix.com/

I'm not sure if the recursive hierarchical conceptual inference as well as many other things would have been possible without Common Lisp.

Interestingly it seems that there was no (extended?) mention of Common Lisp on the JVM: Armed Bear Common Lisp. It is not central to the argument, but if one were to decide to migrate from clojure to common lisp, I'd say that one low risk path would be to first validate that you are capable of working with common lisp, and only then start preparing to forego / replace all of your dependencies, which is one of the strong parts of clojure: the ability to leverage everything under the sun that exists in the java / jvm world.

> By embracing Common Lisp over Clojure and the JVM, we’re not only choosing a powerful programming language but also making a greener choice for the environment.

My eyes just rolled so far back in my head I can see my skull.

I quickly went through the slides, and this point regardling Sun, IBM and Oracle's java alliance just doesn't make any sense.

> "Aimed to counter Microsoft’s .NET framework"

First of all the alliace came to be during the 1996 - 2001 timeframe that predated .NET.

When Network Computer came out there was no .NET.

When Oracle adopted Java into their database ecosystem there was no .NET.

When IBM refocused from Smalltalk into Java, there was no .NET.

Secondly, .NET was only born with C#, after Sun's lawsuit due to J++ language extensions (J/Direct reborn as P/Invoke, COM interop, WFC reborn as Windows Forms, events).

Had it not been for the lawsuit, the updated COM Runtime being researched would have most likely used J++, as shown on the Ext-VOS paper.

Also 20 years later, Microsfot saw they had to embrace Java on Azure, and they are now an OpenJDK contributor with their own distribution, talk about strange ironies.

To me, the most compelling aspect of Clojure is it's very well designed standard library and ecosystem access via Java. Pretty much everything else is a negative.

Even then, the ecosystem is a Faustian bargain.

Racket is just such a better language and community in just about every way. CL has always felt like the C++ of LISPs in terms of both the language and its (imo) snobby community. I’m open to being convinced otherwise, but I generally have about zero desire to touch it. Even regarding performance (claims being questionable and subjective, almost always), the ease with which one can do FFI with racket is meaningful — I would much rather delegate to a lower-level langauge via FFI than muddle around with a pita higher-level language with supposedly better performance semantics.

Aside: this is also an argument, for example, for even using python and rust (one of the most depressing things that led me to quitting Google last year was a manager that demanded C++ for performance reasons over Rust despite being off-g3 and it being an utter nightmare to bikeshed about C++ libraries) when someone tells you that you “need” to use C++ for performance.

Is it possible to build SBCL on my quest 3? Would I be able to generate bindings to vulkan and/or openxr with c2ffi or cl-autowrap? It seems like it would be cool to run swank, connect to it with my desktop, and build stuff. Bu

Ya I stopped watching when he said Java was created to counter dot net (at 6:10)

Time to again link to "The Rise and Fall of Lisp at the Jet Propulsion Lab" (2002)

https://flownet.com/gat/jpl-lisp.html