I recommend Fset, which other commetners have mentioned.
I wrote a wrapper for it and SERIES, called folio, followed by a revised version called folio2. If your requirements resemble mine when I wrote it, you might findit useful.
What I do: Write pure functions, but don't shy away from mutating lexically scoped state in order to improve performance. For global stuff, wrap it with classes since objects are a commonly understood way to reason about state.
Are you aware of any memory-leak issues with fset? I once used it in a game where I updated an fset sequence in real-time. I let it run for a while, after coming back I noticed my computer was completely frozen (out of RAM).
It probably isn't. The initial public release of Clojure was in the fall of 2007. Scott Burson has been working on FSet since at least 2004. He himself says it's inspired by Refine.
Just personal preference and enjoy programming in it. Programmers give too much importance to programming languages.
Clojure can be made to run very fast (it compiles to the same bytecode as Java after all) for the hot paths at the cost at writing less idiomatic Clojure.
By the way, I found a lot of your best practices questionable to say the least. Since it's obvious that you are a newcomer to CL, I would refrain from producing "best practices" type blog posts until I had a few years of experience under my belt.
For that reason, I also found your post confusing and I'm inclined to categorize it as "mostly rehashing stuff that is already there" rather than strong signal. There is ample, good, introductory material for CL on the net, we should strive to think before we dilute it with derivative posts.
I understand your comment as a bit judgmental, if not rude.
Please keep the tone friendly, it helps if we want to have constructive discussions.
I'd be happy (as well as everyone around here I'm sure) to discuss what you find questionable.
I agree with GP about refraining from "best practices" type advice -- at most leave it as "I prefer doing it this way". (Example: There was no mention of qlot for a form of version pinning, which would be considered a "best" or at least "standard" practice in other ecosystems, but while I use it I'm not going to insist other Lispers I don't work with do so too. They can keep doing things how they like. Common Lisp is not for the strongly opinionated.)
Apart from that though I do think it's useful to have the occasional new posts showcasing rebuttals to a few "myths" that won't die, so I appreciated your post. Some gifs of editor interactivity (like in https://malisper.me/debugging-lisp-part-1-recompilation/) would make it better. Though ironically (one myth has been "it has no libraries") perhaps some people might be turned off by the mention of so many libraries ("ok such-and-such is there after all but I have to type a quickload, why can't it come without any work?" -- programmers are often lazy in the worst ways). Before using every utility library under the sun and then some, I'd encourage people to get to know the base language... It's typically quite sufficient for many tasks. But hey, libraries are cool too.
Right, maybe "best practices" was poorly worded. I'll think of something better.
Regarding the visual aspect: Very nice link, thanks for sharing!
I was also thinking of showing off the macro-stepper.
Regarding the lack of libraries: well, Quicklisp is strong of some 1500 libs, which is rather poor compared to most popular languages out there. So yes, it goes both ways!
I wrote a wrapper for it and SERIES, called folio, followed by a revised version called folio2. If your requirements resemble mine when I wrote it, you might findit useful.
You can find it here: