colingw

Thank you for this. There is occasionally disagreement about what "Common Lisp" even means, and the spec is often cited, but as far as all of my posts, library work, and application work are concerned, Common Lisp means "the current reality of the major compilers as implemented in 2025". This is a descriptive / bottom-up definition, and as an active author of software it is the one I'm more concerned with. For instance, `:local-nicknames` have been essentially universally implemented among the compilers, despite not being part of the spec. To me, this makes that feature "part of Common Lisp", especially since basically all CL software written today assumes its availability.

You're right to point out too that the post is somewhat SBCL-centric - this too reflects a descriptive reality that most new CL software is written with SBCL in mind first. Despite that I'd always encourage library authors to write as compatible code as possible, since it's really not that hard, and other compilers absolutely have value (I use several).

This was also my impression when reading the article, as someone who uses Sly heavily, every day. I can't imagine not having in-editor access to functionality like recompiling the function at point, or live evaluation of testing forms directly from the buffer. As Stew (the Clojure guy) pointed out in a video from a number of years ago, nobody should be typing anything raw into the in-editor REPL prompt; you should be sending forms directly from the code buffer.

How do I maintain that workflow if I'm to use native REPLs?

No Emacs entry under editors, and no Clojure in the languages section? Somebody on the survey team had a bone to pick.

Fixed, thank you.

Thanks for this! I'll look into compressing the `.exe` down.

With regards to licensing, I think I'm okay. Raylib itself is permissive, and I own the rest of the dependencies (save two - one is MIT and the other is public domain).

A gem from my grandmother's kitchen.

Not so for Clojure, there's great integration for both the Vim family and VSCode.

I should make it clear that I haven't left Rust; I write it every day professionally.

I transitioned from Haskell to Rust to capture efficiency and small binaries. Since I'm in the game of shipping CLI tools, this was important for me.

You're right though that Lisp is on the other end of that; we're back to bigger runtimes with no tree-shaking, since that would hinder debugging. For now I'm experimenting with the Interactive Programming paradigm because the debugging story is just too good. For long-lived programs, this may be the way to go.

Rust code can be made nice to look at it, but it isn't the default nor the trend.

The questions were originally posed by a Doom Emacs community member, so I answered them as-is.

The site is designs as it is because I'm not a frontend guy xD

CL-embedded langs like Coalton and April are mentioned in the article.