Lisp Journey is a Common Lisp programmer's blog covering the language's ecosystem, tooling, yearly reviews, and comparisons with Python.
HN links it for Common Lisp ecosystem reviews and notes on Hacker News's own Lisp stack, and commenters like its framing of the standard as stable.
I'm a bit fond of the short 5-part series here https://malisper.me/debugging-lisp-part-1-recompilation/ that covers some of the debugging aspects, it's got some animated gifs. But there are several screencasts referenced on https://lisp-journey.gitlab.io/resources/ that may be worth exploring, though the fastest method is probably to just try building something yourself with the constraint that you never restart your Lisp image. Not too long ago I ported an old 2D maze generator I made in pygame to CL with SDL2, then while I had it up I decided I should add a solver to it, so ported an old A-star implementation I wrote in C++ and hooked up drawing (with dots) a path from any point to any other point. Then I wanted to draw a nicer sprite path that connected and handled corners by curving, so I swapped those in and then one-by-one recompiled the code with new ifs to handle each corner case to select the right path tile. Having to close and relaunch and reset the test points (and save and restore the maze seed) every time I made a code change would have been rather tedious.
If you've worked in Java, download the JRebel extension for more complete hot-reloading support, and that'll give you an approximation of the interactive development experience. It's especially useful for web apps where you can change the code for an endpoint (or used by several endpoints, whatever) and can then just test it out with new requests, no need to restart the server.
What I look for in a language first is how good the support is for concurrency, and especially if it has a good, modern concurrent garbage collector.
A quick search brought up this:
https://lisp-journey.gitlab.io/blog/pro-mailing-list-on-common-lisp-and-parallel-gc/
> This was primarily for the lack of good parallel, concurrent garbage collectors in Common Lisp implementations. The CL version of elPrep was actually still a tad faster than any of the C++, Go, or Java versions, but we had to work hard to avoid long GC pauses. elPrep allocates a lot of memory, and the pause time hurts a lot. We solved this by, basically, disabling the garbage collector, and reusing memory manually as much as possible, which turned the program into almost a manually memory-managed affair.
Super-interactive workflow. You never wait for the webserver to restart -you are "inside" the server/the running image.
Super-fast compile-time errors and warnings (function by function, a shortcut away).
Compiles to machine code.
Djula is nearly a drop-in replacement for Django templates. Or choose JSX syntax or a lispy template engine.
Various DB libraries, Mito has built-in migrations.
Binaries with everything included (templates and all static assets, dozens of dependencies, the compiler and debugger) is ±35MB (compressed). Great to ship and deploy.
An in-coming DB admin dashboard (https://lisp-journey.gitlab.io/blog/towards-a-database-admin-dashboard-for-common-lisp/)
Good times.
Sort of need to ground it from an economic point of view, not point out like an ethical statement or a procedural issues.
The common is solved surprisingly by enforcing rights and individuals sharing with group. The dynamics of the maintainer net and the consumer net plus their interaction is an interesting topic.
The topic is sound too high.
It should touch either theoretical summary and recommendation or practical one like issues raised here as maintainer and copycat say : https://lisp-journey.gitlab.io/blog/why-turtl-switched-from-lisp-to-js/
I've not really encountered any situations where I've needed to do anything like this yet (still learning), but, I found this example, where there's an existing function, and someone alters the body of the function to create a new function. My guess is that there's various ways of doing this type of stuff: https://stackoverflow.com/a/1220198
Edit: a macro example, which I think may be the more common route of doing this type of stuff? https://lisp-journey.gitlab.io/blog/common-lisp-macros-by-example-tutorial/
> A real killer feature would be some kind of emacs-lisp compatibility layer so that you could load existing third-party emacs modules, but I imagine the complexity of that is so off the charts that it would be unrealistic.
Yeah while completely unrealistic some way to make interfacing with emacs packages would be nice.
There seems to be a magit like interface in the works: https://lisp-journey.gitlab.io/blog/oh-no-i-started-a-magit-like-plugin-for-the-lem-editor/