It’s good that it’s fast. Still no good enough!

But "live" is a whole different thing. And most languages aren't built with the expectation that you'll be patching it while it's running - at least as standard operating procedure and without nuking state.

And that's a key part.

I think you should be able to build an app and develop a game without ever having to restart them.

And that would come with new challenges and the need for new tooling / constructs. E.g. When you change a type / structure, and there's existing state, what happens? (migration, deletion etc)

Dynamic libraries for languages designed from scratch to support such features, have runtime support to handle all reloading use cases, like in Xerox PARC OSes, and inspirations thereof.

Traditional dynamic libraries for UNIX and Windows, are designed with C in mind, thus quite fragile to implement similar capabilities.

The short of it is, you need a communication medium between LSP and your program. When you edit a text file, it needs to tell the program it updated, along with the latest text.

To communicate the values of variables is more work- you need a way to keep track of all changes to all variables. I wrote auto instrumentation code that wraps every modification to every variable in the files it instruments (which for livelove is everything but the library files themselves). Obviously this isn't perfect, but it does pretty well- and to see the value of anything you just need to make sure it's assigned to something somewhere or modified (very likely already the case).

---

There are absolutely hot reload Lua libraries- there's even an IDE where this is a key feature!

https://studio.zerobrane.com/

I dunno what you are using but we are a small team working on large codebases; one in js/ts mix, one in python and one in cl. Everyone cannot wait for it to be CL time; everything js and especially ts feels so incredibly clunky and half baked. The debuggers are awful and actually don't even stop on breakpoints a lot of the time for no apparent reason.

For most things in cl you have libraries (async etc) and for the rest you roll your own (much) faster than you can try out the tearinducing garbage on npm to figure out what half baked buggy thing might fit your purpose (before it gets hijacked by some north Korean hacker group of ofcourse). With LLMs this has become way easier.

Using the strong typesystem cl has and then adding on coalton when you need it, I prefer over typescript, if only for the speed of dev / no noticeable recompile.

(I don't know for popularity but my personal opinion is that CL is still unmatched: this level of interactive development + good debugging tools + excellent implementation that compiles to fast machine code + fast startup for binaries + self-contained binaries + stable yet improving language, implementations and ecosystem + connect from a running program + commercial vendors if you need + … such a unique and productive set)

(re. the type system: https://github.com/coalton-lang/coalton/ for a Haskell on top of CL now)

Packages are namespaces, unrelated to modules. They are not used to organize dependencies but to remove ambiguity of naming and to provide encapsulation.

> The progress in CL development is severely hampered by the set-in-stone standard, small pool of users

The language is extensible, compilers do get new features added, sometimes in a coordinated manner. Standard being stable is not that significant an obstacle to moving forward; pool of users being small is much more noticeable. Yet more noticeable is that community is less healthy than the Emacs one. This comparison is valid because development in Emacs Lisp is attractive for the same reasons, unique to it and CL; they also happen to have extremely similar syntax. Elisp is moving forward steadily, and in recent years quite rapidly. CL would progress forward similarly, or better, had it had something like Emacs that provided that synergetic effect.

Things have changed since 2015, though, and in 2015 looking back at 2005 things had changed too. (Quicklisp was only on the scene in 2010, which is somewhat late compared to its equivalents in other languages.) Popularity-wise, I continue to be positive about CL's global future, even if nothing is done about your bullet points. Over the years I keep noticing new software, new implementation features, the occasional new book, new papers, new jobs, and new people writing stuff, I expect that to continue. Some long-standing companies and systems are still going, avoiding the death of a total rewrite or just better competition, some of them like managing train schedules are older than me. It looks like a living and (slowly) growing ecosystem. It won't ever again enjoy a top-10 language status by making technical changes, but I don't think many people care. (There's a similar level of not caring when it comes to non-GC languages and how their overall job market share is probably not going to shift from ~10% any time soon (barring the potential of forced mass early retirement due to AI).)

I was considering a more argumentative reply to your bullet points because I think they're not quite correct... There's a lot of nitpicking that could be done, and further elaborating the nuances might lead to a conclusion that, to the extent the points are true, they don't really matter -- in other words, my reaction to the list even in its strongest form (by my views anyway) is still kind of just a big shrug, so why bother trying to argue with it? I'll keep using Common Lisp. (Even despite my own pet complaints not on your list.) And given your final statement about sticking with it, I wonder if you also kind of shrug at the importance of those things.

https://github.com/xyproto/sdl2-examples/blob/main/lisp/Make...