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).

The original intent was that `simple-array`, on its own, is not related to `string`. The referenced type hierarchy makes this clearer: https://lispcookbook.github.io/cl-cookbook/strings.html#stri...

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).

Thanks for the tip. I double-checked, and while there is no difference between 0 and 1 for SBCL and ABCL, there is a slowdown for ECL.

I've elaborated here:

https://www.fosskers.ca/en/blog/optimizing-common-lisp#orgb5...

A gem from my grandmother's kitchen.

I have being using Trial[1] for the past few weeks to test out game development in Common Lisp, and have been having a great time. Being able to alter (almost) all aspects of your game while it's running is a blessing.

I hope this port succeeds.

[1]: https://github.com/Shirakumo/trial

This is the Trial game engine[1]. I've been using it recently to making a small game[2], and can say it's quite nice to be able to hot reload functions to test logic, collisions, etc. without having to restart the game. The Trial author has been working on porting it to the Switch to expand the reach of the game Kandria[3] (and other future CL games).

[1] https://github.com/Shirakumo/trial

[2] https://github.com/fosskers/save-the-farm

[3] https://github.com/Shirakumo/kandria

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.

If the Stackoverflow Dev Survey is to be believed, CL and Clojure devs actually make decent money.

To be the most fair, Fennel 1.4 recently released with an `assert-repl` form that opens a repl when some assertion fails, in which you can inspect local variables, etc. That's getting closer to CL.

https://git.sr.ht/~technomancy/fennel/tree/1.4.0/item/change...

The Clojure Slack has active channels for both job posters and job seekers.

Manual recursion often isn't needed. You can get basically all of what you want from Transducers: https://github.com/fosskers/cl-transducers

Hi. I actually left Haskell for Rust. And when I say "left", I mean I don't start new projects in it. I still maintain my libraries.

I wrote Haskell for 10 years or so, both FOSS and professionally. I've "been around the block" so to speak and consider myself to have a decent view of the landscape. Overall, Rust lets me code in the style I want while being very resource efficient. I write Rust professionally.

Yes, it's more than just about the language itself, as I describe here: https://www.fosskers.ca/en/blog/software-dev-langs

For some people, community signals are very important. Massive conferences or raw number of libraries, etc., indicate some inner quality of that language's ecosystem that they value.

Yes, although that solution can't yet be said to be "push button". My impression is that there are a decent amount of people who want non-JVM, native Clojure. Hence efforts like Janet and Jank.

If you're looking for Transducers in other Lisps, I'm working on a porting-and-API unification project here: https://sr.ht/~fosskers/transducers/sources

Note that the Emacs Lisp variant is still under development. Once things looks good, we'd like to circle back around to Scheme's SRFI-171 (mentioned elsewhere here) and possibly redo it to include more fundamental primitives.

I hope they find the ruins of Numenor soon.

Rust's `cargo` kicks the crap out of either of them.

It can sometimes be an issue in certain "Gotta go fast" scenarios, where you'd otherwise be able to reason quite confidently about program behaviour with a strict language.

So what is "Haskell itself"? Writing everything with the Prelude and the `IO` Monad?

Sure some people go off the rails with some things, but it's possible to write mostly vanilla Haskell and get a lot done.

This is Part 3 of an on-going series about the usage of various languages for real-world software development.

Luckily tools are available for all of that, many of them through Sway directly. Interested folks can check out the Sway Wiki.