The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.
What exactly are people “expecting” from an executable? It is a piece of binary code on disk, full of machine code, that runs without a VM or external runtime libraries.
./mycoolprog
just works. From a user perspective, there’s no difference.
The binary itself isn’t structured like a typical one with C debugging symbols, etc. But it’s also not some “faux binary” like a bunch of .pyc bundled as data and unzipped when the program runs. It truly is machine code, just arranged differently than a bunch of C ABI functions.
I claim most people running binaries don’t care about the memory layout of the binary. I certainly am never thinking about that every time I run `grep`. You don’t debug Lisp programs with C’s tooling. You use Lisp’s tooling.
(Unless, of course, you use an implementation like Embeddable Common Lisp, which does compile your Lisp program as a C program, and does produce a non-image-based executable. That’s the beauty of Lisp being a standardized language with multiple conforming implementations.)
Unfortunately none of the FOSS implementations have this ability (to my knowledge). There is nothing inherently in Common Lisp that mandates the "core dump" delivery model.
