I know I am going to write an unpopular opinion and get downvoted for it, but here it goes...

I am still not convinced by the general "we don't need to upgrade the Common Lisp specification" attitude.

It surely is remarkable as a specification, encompassing so many aspects of the language, yet it leaves so many other aspects to the particular implementation. Multi-threading for example is supported by most major implementations yet their syntax (and often, semantics) are very different from each other. Same goes for cooperative multitasking (corutines etc). Someone else could come up with other examples.

In my opinion a new committee should be formed, to standardize the syntax and semantics of these so common functionalities.

In this sense, the various C++ language working groups are doing a remarkable job. I wish something similar would happen in the Common Lisp world.

My main beef with treating the Common Lisp spec as a sacred text is simple:

1. There were things at the time that were not quite standardizable that are now. Examples: Some degree of concurrency, system definition, the CLOS meta-object protocol, networking.

2. There are things that were created or became important in the meantime that should be standardizable now: Unicode and localization, concurrency building blocks like threads and locks and queues and atomic operations, cryptography, compression, higher level networking (URLs, HTTP, etc.).

3. There are just bugs and holes and incompleteness in the standard due mostly to compromise from the then current vendors. For example, not everything fits the sequence protocols, the language isn’t CLOS all the way down, streams, etc.

All this argues that there’s room for continued progress. The only good argument I’ve heard for why it hasn’t been pursued is “Who’d fund it?”

> the language isn’t CLOS all the way down

I'm curious what you mean by this, why it's needed or would be a good thing, etc. As a multi-paradigm language, I'm not seeing why CL should have a particular paradigm "all the way down".

It's good because it offers the opportunity to simplify and rationalize the type system and associated protocols without losing features.

In the early 1990s I worked on an experimental Newton OS written in Dylan. At that time, Dylan was still called "Ralph," and it was basically an implementation of Scheme in which all datatypes were CLOS classes. It was "CLOS all the way down."

Ralph offered substantially the same affordances and conveniences as Common Lisp, but with a simpler and more coherent set of APIs. Ralph was easier to learn and remember, and easier to extend.

To illustrate why, consider finite maps. The idea of a finite map is a convenient abstraction with a well-defined API. Common Lisp offers a couple of convenient ways to represent finite maps, and it's easy to build new representations of them, but there's no generic API for finite maps. Instead, each representation has its own distinct API that has nothing particularly to do with anything else.

By contrast, Ralph had a single well-defined API that worked with any representation of finite maps, whether built-in or user defined.

The upshot is a library of datatypes that is just as rich as Common Lisp's, but with a simpler and more coherent set of APIs, and an easy standard way to extend them with user-defined types that also support the same APIs.

There are signs in the Common Lisp standard that people were already thinking in that direction when the standard was defined. See the sequence functions, for example. Ralph, designed by Common Lisp and Smalltalk implementors, carried that thinking to its logical conclusion, and the result was something like a tidier Common Lisp.

Twenty-eight years later, Ralph is still my favorite of all the languages I've used for serious work. Its development system, Leibniz, remains my favorite development system. My favorite current tools are Common Lisp systems, but that's because I can't have Ralph and Leibniz anymore.

What's your opinion on Julia given its Dylan heritage?

Julia is almost good enough for me to use, but not quite. I'd prefer an s-expression syntax, but that's not a deal killer for me. I like some other languages that don't have s-expression syntaxes, though I miss the easy text manipulation that s-expressions support.

I would want a convenient way to deliver a self-contained executable. If there's a simple way to do that with Julia, I don't know about it. I look for it periodically, but haven't found it. If it's there and I've simply overlooked it, then I might actually start using it regularly.

I have a few other nits, but they're just nits. On the whole, I think Julia's pretty nice.

It's a bit rough around the edges, but it does exist: https://github.com/JuliaLang/PackageCompiler.jl