Common Lisp is just tastefully designed. Part of it is the language itself, but also the libraries, and the culture around it. Even tiny things like underscores-in-variable-names versus camelCaseVariableNames has knock on effects like encouraging descriptive names. It’s hard to distill it into just one feature.

hyphenated-names also makes it much easier to see and remember whether you split something that might be a compound word- did i call it hotDog or hotdog? while hot-dog jumps out as more distinct and harder to mix up with hotdog

plus the canonicalization as ALL-CAPS makes it easy to point out SYMBOLS among the prose of documentation

edit: and people make fun of it for having like six equality functions, but at least it's only got one false value

I don't think it's just the features of Lisp, but rather how they interact.

One thing I realized about Doom (1993 video game) is that -- sure, it's got scary monsters and cool weapons, but what really makes the game awesome is how these elements interact with each other. For example, an Imp has just enough health to be taken down with one shotgun blast, so in the early stages of the game, getting anything stronger than the pistol will be a priority when you encounter a pack of Imps. And a Cacodemon is very dangerous, but it has a high chance to stun, so you can pretty safely kill it by stun-locking it with a rapid-fire weapon like the chaingun. The way the monsters behave, together with the terrain, allowed the developers to combine just a few elements to create a huge variety of combat situations that pretty much required the use of every single weapon, and a variety of skills and strategies from the player.

And, not only did this make Doom a more exciting game to play, it opened up an enormous possibility space for user-generated content that a dedicated fan base is still exploring nearly three decades later.

Lisp is like that. It's not just that it has a REPL, or macros, or homoiconicity, a fast compiler, incremental development, or that the evaluator is itself built into the runtime -- it's that it has all those things, they compose nicely, and they interact in such a way that it opens up a tremendously huge possibility space to even a single programmer that other languages do not. Could you countenance writing an expert system in Java? It's possible, but it would be tedious work.

And Lisp's dedicated fans are still exploring that space today, six decades later.

I completely agree, many people look at a language as the sum of its features, but it really isn't.

Also, I think Lispy syntax is key in REPL ergonomics. It means you can, more often than not, take a chunk of code and trivially insert it into the REPL.

Yeah, I absolutely agree. It really isn't about the laundry list, but how the parts come together to form a whole.

But I understand that, to many, it still sounds handwavy and nondescript. The Doom comparison is great; I'll keep that in my pocket.

how do you go about producing static binaries for sbcl?

Load your application up in SBCL and call `save-lisp-and-die` with the options you want (like what the `main` function should be).

Like this, it's easy: https://lispcookbook.github.io/cl-cookbook/scripting.html#wi... (save-lisp-and-die run from a terminal)

You don't. As others noted, you can save a core image. Cross compiling, tree shaking, and other such things don't exist in the sbcl world and (from what I've read in the past) the people developing it have little or no interest in those features.

If you need those sorts of features paired with common lisp you could give embeddable common lisp a try. Otherwise if any lisp language will work for you then chicken scheme and gambit scheme both compile to c.

> save a core image.

which can be made executable. So saving an image is the way to create an executable.

> the people developing it have little or no interest in those features

the demand for these features from the SBCL user base also does not seem high. If it would have been needed, then the development could have been sponsored, like for example the support for Apple Silicon was sponsored by users.

Though other CL implementations provide different deployment options:

ABCL compiles to JVM code.

ECL can compile to C or portable byte code. It also has been used for Android and iOS apps.

LispWorks & Allegro CL have treeshakers and can generate shared libraries. LispWorks also has a runtime for Android and for iOS.

SBCL certainly produces an executable containing fully native machine code. You can ./run it just fine.

I consider how it arranges that code (the "image" you speak of) to be merely an implementation detail that the user is not concerned with.

> tree shaking

The technique of 'tree shaking' was originally developed for lisp.

And? When I last checked sbcl didn't support it. Are you implying that has changed?

Neither did sbcl support cross compiling. To the best of my knowledge all you can do with sbcl is save an image.

When I was looking in to this I read through many discussions where the developers appeared hostile to the idea of implementing these features. A common refrain I encountered was that tree shaking is unnecessary because the core images are compressed.

You can delete data from the image if you want. We used to do it: scrub all doc strings, inlining data, etc. It's trivial.

In 2022, removing a few megabytes of data doesn't seem worth the maintenance cost of the feature. In other words, for most users, it's a non-problem.

Tree shaking isn't data removal, it's dead code removal.

And assuming he doesn't want what he wants is kind of in bad taste. You don't know his requirements.

As far as I'm concerned, as a Lisp programmer, code is data. :)

Yes, and what exactly constitutes "dead code"? Tree shakers rely on heuristics that can fail in practice. There is provably no way to remove functions from a Lisp image and guarantee your application to work. LispWorks has a "tree shaker", but has umpteen options to tame it so your application doesn't inadvertently break.

Fortunately, it is possible to remove these functions if you, an application developer, so please. Nothing stops you. It's not even difficult. But SBCL has not implemented these (potentially fallible) heuristics for you, because (and only because) an insignificant number of users would find shaving a little binary size off to be valuable at the expense of program correctness.

In 2022, if you're linked to libc.so, it's probably substantially bigger than your Lisp image, and so that's where you'd want the tree shaking. Good luck!

The kernel supports manual tree shaking: "make menuconfig" and prune away.

SBCL supports saving compressed images so even without tree shaking, standalone executables are small. Not a problem.

I pay for a maintenance contract and licensing for LispWorks that does support tree shaking.

I wonder if there isn't a generally distributed congenital allergy to parentheses.