Lisp is very well-suited to live development due to code being data, but live development doesn't need to be lispy.
I built a live development extension for Love2D which lets you do graphics livecoding (both lua and glsl) in real-time - every keystroke updating the output, (if a valid program).
So many cool things once you break down the barrier between editor and running program.
I've also asked myself the question of, what would a language look like that was natively built for live development, and built out a prototype - though it's definitely a sandbox so haven't posted it anywhere yet, other than demos on mastadon.
Oh wow, just had to log in and give you a high-five for livelove because this is the first I've heard of it and it sounds like the sort of thing I absolutely need to try out.
I remember giving Love2D a go a couple of years ago with Fennel and the lack of such a thing sent me grumbling back to Common Lisp. I'd never even have thought of building that functionality in Love/Lua myself - assuming it's something that the runtime just didn't support - and it absolutely would never have occurred to me to use LSP to set it up. I've not even used it yet and it's already doing things to my brain, so thanks!
I guess the prevailing worldview is that "recompile everything and re-run" is good enough if it takes 2 seconds. But agreed that it just "feels" different when you're doing live in lisp... I miss Emacs!
Well, for me it’s not enough because I need to get back to where I was, repeating the same actions so it gets to the same state. With live dev I don’t need this, or a history replay method. I only update the running code. Heck I could also update the in memory var too if so I want.
Recompile and hot reload, maybe. 2 seconds if you're very lucky. Many setups are much slower. I've seen some really cool projects over the last few years- things like tcc + hot reload that have really good turn around time.
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)
Can't you just do live code reloading with a DLL? Have a small core which is the exe, and then all of the logic is a DLL which can be reloaded when the core detects changes to the dependent files...
Kind of, but there is a reason this is a whole business, see Live++.
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.
Have you done some kind of a write-up on how to do this? Lua is popular enough that I suspect there might actually be a demand of a readymade library to use hot reloading.
I haven't done a write up- I could, for sure. The code is all open source and the Lua side is only a few files.
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!
I use Common Lisp (CL) for some of my small personal projects. A few publicly available examples I can share include my website [1] and a now-defunct mathematics pastebin [2]. My CL projects are usually text-oriented, not graphics-oriented. What keeps me coming back to CL is how convenient the live coding environment is.
When I am exploring ideas that are not fully concrete yet, I can begin by writing a small set of functions with very basic functionality. Then as the ideas evolve, I can refine existing functions or add new ones, then quickly "reload" them (with say, C-M-x in Emacs), and see the effects immediately. There is no separate compile or rebuild step. I don't have to restart any service or application. The effects are truly immediate -- what previously did X, now does Y.
In the Python or JavaScript ecosystems, similar live reloading capability is often provided by frameworks (e.g., FastAPI, React, etc.), which monitor file changes during development. In CL, it's just part of the language implementation itself.
Of course, at the end of the day, everything is committed and pushed to a version control system. Sometimes I restart the application too just to be sure it reflects the actual source, especially, after hours of live reloading. The stereotype of Lisp programmers making all of their modifications in an ephemeral image and then dumping it all to disk is not something I have actually seen in practice, at least not among the people I know.
So the rest of the software development practices happen to be typical. But during exploration, debugging, or troubleshooting, the live coding experience in Common Lisp is so seamless, it feels like programming at the speed of thought.
I tried using CL this year for a new version of my personal static site (blog) generator.
Yes, it's incredible and still an alien technology in some respects. Native AOT compilation at the level of functions with hot swapping - and without any ceremony, always available in the IDE - is one of them. As the OP writes at the end, only Smalltalk and Erlang come close.
But, when viewed objectively, in 2025 CL is quite behind in some aspects:
- Only one commercial IDE offers a true graphical debugger. Both SLIME and SLY (I'm not sure about stickers) fall behind JS or Python environments.
- Asynchronicity is based on explicit callbacks or callbacks wrapped in promises (and some macros). No async/await, no coroutines. Since writing async code is harder, people default to sequential code and a thread pool. For IO-bound apps, this unnecessarily adds synchronization problems that would be mostly avoided in single-threaded concurrency.
- Tiny ecosystem of libraries. Due to the stability (or stagnation) of the language, a lot of old code still works, but even with this, finding what you need on Quicklisp can be challenging.
- The stdlib is old, crufty, and quirky. It's also very small by today's "batteries included" standards. Initiatives like CL21 or CIEL try to alleviate this somewhat.
- Even in SBCL, the type system is limited compared to MyPy, TypeScript, or TypedRacket.
- Bolting packages (module system) on top of symbols leads to some problems in practice.
- The progress in CL development is severely hampered by the set-in-stone standard, small pool of users, and the need to reconcile 10 different implementations.
It's still a nice tool for many uses, and the interactive development is indeed comfortable and productive. Still, if nothing significant happens, I don't think CL will have a chance to gain popularity again. Up until now, a successor language was hard to justify - despite some shortcomings, CL was still a language from the future. Now that future is largely here already, so the shortcomings become more and more glaring. There's SICL, but it'll take another decade (if at all) before we can expect results from that.
I'm now looking at Jank and Gerbil with some expectations, though I think I'll stick with CL in my current project.
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)
If you look at awesome-cl you may surmise that Common Lisp has a bit of a dearth of libraries, but a glance at OCICL's repositories shows 79 pages worth of libraries, and Ultralisp even claims to have 2,170 projects. So while it's not at the level of C, Java, or Perl; it's nothing to be sneezed at either.
The fact is that it's so easy to write your own code in CL, that the majority of glue code in NPM, Maven and the likes don't make sense to be written.
An example can be taken from a comparison between VS Code and Emacs. In the former, you have a whole browser engine and quite a bit of code to implement an editor on top of that. In the latter, you just have some primitive and the rest of it is LISP implementing multiple applications. LISP encourages less layers because the data structures and the language are so flexible.
> Bolting packages (module system) on top of symbols leads to some problems in practice.
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.
It's funny but I think your exact comment could have been written 10 years ago, substituting 2025 with 2015. Some things might be ±2 years. This observation could be seen as both a positive and a negative about both the language and people writing about it.
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.
> I wonder if you also kind of shrug at the importance of those things.
Yes, to an extent. I suspect I could nitpick on the points ("but X still works", "this isn't how you work with CL", "it's still better than alternatives", "you can work around that") just as easily as you. I still like working with Common Lisp, after all. Even the worst offender on my list - no native coroutines (or continuations) support - was true for both Python and JavaScript for most of their history. And in their cases, there was no way to sweeten the syntax with macros (as BlackBird does for CL). So yeah, these are all shruggable, even if ever more embarrassing as time passes and the rest of the world leaves some of the issues behind.
That was such an unexpected claim, I had to look up on which platforms CMUCL currently runs. Seems it has been ported to MacOS (which I take you are referring to as there are perfectly fine working X11 servers available for M$ Windows). Kudos. If I'd be using MacOS, I'd have also a look at Clozure CL (CCL).
My bad, I mean source-level debugger. Something that allows you to step through forms as they are in the source, unexpanded and not decompiled. It should allow jumping to a line or over an expression, continuing to a point, seamlessly stepping into subroutines, and stepping out of expressions. It would be nice to have single-activation and conditional breakpoints. Variables in the executed portion of the code should be annotated with their values. Sometimes watchers - forms auto-evalled in each frame - are helpful, though these are implemented in some CLs, IIRC. SLY's stickers are close, but they are gathered during execution and replayed later, so the break-edit-recompile-redo workflow doesn't work with them. My experience debugging CL using SBCL and SLIME reminds me of debugging CoffeeScript in a browser before source maps were a thing... It's still 100% doable, just less convenient.
Cool, I'm assuming this is largely driven by mouse usage, as well?
I'm always baffled by how long it has been since I was used to step debugging. It was definitely something that was huge when I was learning, but seemed to get left behind by so many practices.
My general memory is that it was growing and the likes of JRebel were aiming for very powerful uses of debugger connected development experiences. Eclipse, as I recall, have their own compiler specifically to let you debug code that isn't completed. Then, cloud technologies largely came and many just lost track of what could be done.
A fun example, I remember senior engineers at Amazon that didn't know you could hot patch Java while step debugging. Something that they had largely never had a chance to do, because of the standard deployment processes they had been used to.
To the direct point, I am somewhat surprised these aren't doable in Common Lisp. I saw examples showing these years ago, just without the GUI affordances that were in some of the other IDEs. https://malisper.me/debugging-lisp-part-5-miscellaneous/ has examples of the trace command offering conditional breaks and such. Sounds like there is the functionality, but lacking the visual cues/affordances?
> Sounds like there is the functionality, but lacking the visual cues/affordances?
Yeah, some things are missing (arbitrarily moving control to a given line (even if it precedes the current one) in a function, stepping into some functions[1]), but mostly they're there, just clunky to access and view. It's getting better, though - I checked the cookbook page[2] and found a project[3] that I didn't notice previously, which should help quite a bit with convenience. Even with that, though, LispWorks[4] still looks better... ;)
[1] The ones compiled with a low `debug` setting; they're either impossible to step into, or you land in the decompiled source. Trying to step into a function call should recompile that function automatically with debug instrumentation enabled.
One of the reasons I kept around Java and .NET ecosystems on my toolbox, regardless of their lack of coolness by modern coffee shop coding standards, is exactly the traces of Smalltalk/Lisp development experience that somehow are part of the tooling and runtime capabilities.
By the way, it is relatively easy to plug a debugger into a running container in a Kubernetes pod.
Yeah too many folks pretending their systems are UNIX in 1980's, and not aware of what is available.
I frequently try to mention how Java with JRebel is the closest to the Lisp experience I've found with non-Lisp, it's more dynamic feeling than so-called dynamic languages. Having something like the condition system being ubiquitous would be golden. (I'm aware there is a Java port though I never got around to playing with it and it doesn't solve the problem of other people's code not using it..) My last big job involved a giant app server that would take minutes just to restart if you had to do it, JRebel saved so much time by making things much more reloadable including support for a lot of other libraries' quirks and in general a lot of Java-isms like things configured with XML. Looking under the hood at the JVM you can see traces of Lisp everywhere, like class loaders are just (load)s, it's easy to believe the quote about dragging C++ programmers halfway to Lisp.
Then there's things like rr (https://rr-project.org/) that also seem largely ignored by old unix systems people, despite being exactly appropriate for that environment.
Still, having the whole language available via REPL as Lisp does when you hit a break or error makes up for a lot of weaknesses in the rest of the debugging experience.
I haven't met the individuals like taeric but I do find it plausible that something has been lost for developers whose main experience is in highly separated cloud-oriented systems, whether they go as far as micro-services or not. When you don't have full end-to-end debugging and have to correlate everything with trace ids in logs, and also if policies prevent even getting a debugger hook in production, I can see how one would be less motivated to learn about debugging tools to begin with. (On the other hand you're encouraged to have better logging, and often that's enough to figure out a problem, no need to have a running application.)
Most of the stuff like class loaders came from the Objective-C influence, which naturally has its influences in how Smalltalk and Interlisp-D influenced each other work at Xerox PARC.
JAR files and related structure, are basically redressed NSBundle packages.
Agreed on your last paragraph. Really all of your post. I would oddly find myself arguing against people trying to make a complicated step debug mock setup to simulate the deployed environment when looking for bugs. A general socratic approach to the behavior you were witnessing was a valuable way to find bugs.
To me, the connected debugger was far more interesting as a development tool than a debugging one. Despite the name.
I think the 1980s probably had higher debugger use than today. :)
I was specifically thinking of things like Cloudflare Functions and AWS Lambda, for the deployments that you can't really step debug. They both have ways, nowadays; but nothing that would let you do a hot patch to fix anything.
Granted, my example of senior engineers would be odd there. They definitely were deploying code as standard jar files to machines. Not sure why they didn't know of this. Even the more complicated war files were straight forward to connect to.
Further granted that this isn't something you could realistically do to a fleet of machines. Guessing that is why they didn't ever try to use it.
I think a recent update (March 3rd, version 2.5.3) to SBCL added this sorta breakpoint debugging functionality. Hopefully we'll see it integrated with SLIME soon.
> enhancement: breakpoint debugger commands have been added. Included is a stepper based on breakpoints requiring no extra instrumentation. However, it still has less functionality than the existing single stepper. See the new debugger manual section titled "Breakpoint Commands" for more information on the new commands.
Processing is what ignited my passion for programming and Quil has become my favorite way of writing it. It is amazing that you can re-evaluate the draw/update function in a running sketch and immediately see the changes, without having to reload the whole thing. And on top of it you have the beauty of the whole Clojure Stdlib with its immutable datastructures.
I just learned that there is now a tweak mode in Processing that lets you tweak certain parameters in the code (via draggable values, etc.) while the sketch is running, which is pretty awesome for experimenting with values. However, you still have to reload the whole sketch when you want to change other parts of the code, you can’t just eval a function in the editor and get immediate feedback like in Quil.
If you mean translating from the JavaScript, yes. Quil wraps Processing. Quil did not wrap the vector library (P5.Vector) but most of vector operations are pretty easy to write in base clojure or you can use clojure.matrix. The fun(ctional)-mode lines up with passing initial state through the functions, which clojure makes easy.
This reminds me of the excellent CEPL library (https://github.com/cbaggers/cepl). You can write live shader like programs with cepl with an OpenGL backend.
Among the plethora of strong suits that Common Lisp brings along, the live coding is hands down the best part of it. There is just no better way to experience programming than that.
Sure, the condition system is awesome, CLOS is next to nothing, but the live coding just wins al the way. All the other aspects are just icing on the cake for me.
Reminds me of something from like 2007ish(?)~ called (fluxus). It was a lisp text editor with a render target in the background and some nice standard library for making 3d objects appear or sfx play. Everything was constantly evaluating/hotloading in the background.
So much fun, I can't find any of the videos in a quick search, so maybe lost to time. Great performative lisping in them hills though.
Working on a largeish typescript node project right now and no support for recompiling a single function in a live system means I have a good minute of downtime on every change. The lisp paradigm would be so refreshing here.
2) I thought the issue was compilation from TS -> JS. So what's the issue? I remember live coding in JS like 15 years ago, have dev environments just gotten weird and convoluted?
No idea. My working theory is the gotta go fast folks at v8 don’t care about live hot reload because that doesn’t give them ad revenue, so they just wontfixed the whole thing and there is no alternative on the backend if you want typescript.
This doesn't make sense because you can definitely do live coding in Chrome devtools (which uses V8 of course) and in Nodejs (--watch will reload code changes automatically and there's ways to keep application state through code changes).
Love this. Sketch, in particular, looks really exciting to me. I'll have to take a look into trying it out. I still have dreams of doing some of the ideas in Turtle Geometry on a modern computer.
I am not sure if this is what you mean, but the original UCBLogo (which I think is used in the Turtle Geometry book) is still alive and maintained[1] (not by the original authors, but Brian Harvey seems to chime in every now and then) and it does run well on modern computers.
Now that I think about it, Logo seems to be pretty much a livecoding environment (not surprising given that it is a Lisp, but with less parentheses). You can define and edit functions from the REPL while the program continues with the same state, the same canvas. You can even pause e.g. a running procedure that draws a polygon, rotate and move the turtle and then continue the polygon procedure with that new state (at least this is possible with UCBLogo).
It is indeed what I had in mind, I was amusingly ignorant that this was being maintained. Humble apologies on my end! Edit: And thanks for correcting me!
This sounds like a great developer experience, but the path from live-coded LISP graphics to a game that can be made public on ie. Steam is a long and troublesome path, compared to using for example OpenGL and C++.
I wish more programming languages focused on quick compilation times, easy cross compilation and straightforward deployment in general.
Live development is still so under-explored, and is just so exciting to work with.
One of my favorite talks is "Stop Writing Dead Programs" (https://www.youtube.com/watch?v=8Ab3ArE8W3s) and touches on a lot of what could be in terms of live development.
Lisp is very well-suited to live development due to code being data, but live development doesn't need to be lispy.
I built a live development extension for Love2D which lets you do graphics livecoding (both lua and glsl) in real-time - every keystroke updating the output, (if a valid program).
https://github.com/jasonjmcghee/livelove
Here are some (early) demos of things you can do with it:
https://gist.github.com/jasonjmcghee/9701aacce85799e0f1c7304...
So many cool things once you break down the barrier between editor and running program.
I've also asked myself the question of, what would a language look like that was natively built for live development, and built out a prototype - though it's definitely a sandbox so haven't posted it anywhere yet, other than demos on mastadon.
Jack Rusher's recent interview is well worth reading too (the "stop writing dead programs" guy).
> On the need to sustain your creative drive in the face of technological change
> https://thecreativeindependent.com/people/multi-disciplinary...
nb. I recently submitted it here: https://news.ycombinator.com/item?id=43759204
That's a great submission! I put it in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so it will get a random placement on HN's front page.
Thanks, dang!
More people need to read Jack's interview, especially in the context of the contemporary tension between generative AI v/s wetware creativity.
I've been plastering that interview in every discord / slack / zulip I lurk in, and been sliding it into everyone's Whatsapp DMs :D
Oh wow, just had to log in and give you a high-five for livelove because this is the first I've heard of it and it sounds like the sort of thing I absolutely need to try out.
I remember giving Love2D a go a couple of years ago with Fennel and the lack of such a thing sent me grumbling back to Common Lisp. I'd never even have thought of building that functionality in Love/Lua myself - assuming it's something that the runtime just didn't support - and it absolutely would never have occurred to me to use LSP to set it up. I've not even used it yet and it's already doing things to my brain, so thanks!
Excited to spread the brain worm. Don't hesitate to join in the fun / log issues / contribute / share how you use it!
I guess the prevailing worldview is that "recompile everything and re-run" is good enough if it takes 2 seconds. But agreed that it just "feels" different when you're doing live in lisp... I miss Emacs!
Well, for me it’s not enough because I need to get back to where I was, repeating the same actions so it gets to the same state. With live dev I don’t need this, or a history replay method. I only update the running code. Heck I could also update the in memory var too if so I want.
It’s good that it’s fast. Still no good enough!
Recompile and hot reload, maybe. 2 seconds if you're very lucky. Many setups are much slower. I've seen some really cool projects over the last few years- things like tcc + hot reload that have really good turn around time.
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)
If you think that feels different download and fire up Squeak which is to Lisp as Lisp is to the recompile and rerun languages.
There are similar trends in music and sound art, which can be experienced with Glicol (https://glicol.org/) as well as many other languages here:
https://github.com/toplap/awesome-livecoding
also this live coding book is free to read!
https://livecodingbook.toplap.org/
Can't you just do live code reloading with a DLL? Have a small core which is the exe, and then all of the logic is a DLL which can be reloaded when the core detects changes to the dependent files...
Kind of, but there is a reason this is a whole business, see Live++.
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.
Have you done some kind of a write-up on how to do this? Lua is popular enough that I suspect there might actually be a demand of a readymade library to use hot reloading.
I haven't done a write up- I could, for sure. The code is all open source and the Lua side is only a few files.
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 use Common Lisp (CL) for some of my small personal projects. A few publicly available examples I can share include my website [1] and a now-defunct mathematics pastebin [2]. My CL projects are usually text-oriented, not graphics-oriented. What keeps me coming back to CL is how convenient the live coding environment is.
When I am exploring ideas that are not fully concrete yet, I can begin by writing a small set of functions with very basic functionality. Then as the ideas evolve, I can refine existing functions or add new ones, then quickly "reload" them (with say, C-M-x in Emacs), and see the effects immediately. There is no separate compile or rebuild step. I don't have to restart any service or application. The effects are truly immediate -- what previously did X, now does Y.
In the Python or JavaScript ecosystems, similar live reloading capability is often provided by frameworks (e.g., FastAPI, React, etc.), which monitor file changes during development. In CL, it's just part of the language implementation itself.
Of course, at the end of the day, everything is committed and pushed to a version control system. Sometimes I restart the application too just to be sure it reflects the actual source, especially, after hours of live reloading. The stereotype of Lisp programmers making all of their modifications in an ephemeral image and then dumping it all to disk is not something I have actually seen in practice, at least not among the people I know.
So the rest of the software development practices happen to be typical. But during exploration, debugging, or troubleshooting, the live coding experience in Common Lisp is so seamless, it feels like programming at the speed of thought.
[1] https://github.com/susam/susam.net
[2] https://github.com/susam/mathb
I tried using CL this year for a new version of my personal static site (blog) generator.
Yes, it's incredible and still an alien technology in some respects. Native AOT compilation at the level of functions with hot swapping - and without any ceremony, always available in the IDE - is one of them. As the OP writes at the end, only Smalltalk and Erlang come close.
But, when viewed objectively, in 2025 CL is quite behind in some aspects:
- Only one commercial IDE offers a true graphical debugger. Both SLIME and SLY (I'm not sure about stickers) fall behind JS or Python environments.
- Asynchronicity is based on explicit callbacks or callbacks wrapped in promises (and some macros). No async/await, no coroutines. Since writing async code is harder, people default to sequential code and a thread pool. For IO-bound apps, this unnecessarily adds synchronization problems that would be mostly avoided in single-threaded concurrency.
- Tiny ecosystem of libraries. Due to the stability (or stagnation) of the language, a lot of old code still works, but even with this, finding what you need on Quicklisp can be challenging.
- The stdlib is old, crufty, and quirky. It's also very small by today's "batteries included" standards. Initiatives like CL21 or CIEL try to alleviate this somewhat.
- Even in SBCL, the type system is limited compared to MyPy, TypeScript, or TypedRacket.
- Bolting packages (module system) on top of symbols leads to some problems in practice.
- The progress in CL development is severely hampered by the set-in-stone standard, small pool of users, and the need to reconcile 10 different implementations.
It's still a nice tool for many uses, and the interactive development is indeed comfortable and productive. Still, if nothing significant happens, I don't think CL will have a chance to gain popularity again. Up until now, a successor language was hard to justify - despite some shortcomings, CL was still a language from the future. Now that future is largely here already, so the shortcomings become more and more glaring. There's SICL, but it'll take another decade (if at all) before we can expect results from that.
I'm now looking at Jank and Gerbil with some expectations, though I think I'll stick with CL in my current project.
> fall behind JS or Python environments.
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.
for folks looking for libraries: https://github.com/CodyReichert/awesome-cl/
(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)
If you look at awesome-cl you may surmise that Common Lisp has a bit of a dearth of libraries, but a glance at OCICL's repositories shows 79 pages worth of libraries, and Ultralisp even claims to have 2,170 projects. So while it's not at the level of C, Java, or Perl; it's nothing to be sneezed at either.
The fact is that it's so easy to write your own code in CL, that the majority of glue code in NPM, Maven and the likes don't make sense to be written.
An example can be taken from a comparison between VS Code and Emacs. In the former, you have a whole browser engine and quite a bit of code to implement an editor on top of that. In the latter, you just have some primitive and the rest of it is LISP implementing multiple applications. LISP encourages less layers because the data structures and the language are so flexible.
> Bolting packages (module system) on top of symbols leads to some problems in practice.
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.
It's funny but I think your exact comment could have been written 10 years ago, substituting 2025 with 2015. Some things might be ±2 years. This observation could be seen as both a positive and a negative about both the language and people writing about it.
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.
> I wonder if you also kind of shrug at the importance of those things.
Yes, to an extent. I suspect I could nitpick on the points ("but X still works", "this isn't how you work with CL", "it's still better than alternatives", "you can work around that") just as easily as you. I still like working with Common Lisp, after all. Even the worst offender on my list - no native coroutines (or continuations) support - was true for both Python and JavaScript for most of their history. And in their cases, there was no way to sweeten the syntax with macros (as BlackBird does for CL). So yeah, these are all shruggable, even if ever more embarrassing as time passes and the rest of the world leaves some of the issues behind.
CMUCL has a graphical debugger.
Unfortunately it looks like only if you are running X11 which cuts most people out.
That was such an unexpected claim, I had to look up on which platforms CMUCL currently runs. Seems it has been ported to MacOS (which I take you are referring to as there are perfectly fine working X11 servers available for M$ Windows). Kudos. If I'd be using MacOS, I'd have also a look at Clozure CL (CCL).
Unfortunately CCL is Intel only on macOS. (macOS is not on the the main page https://ccl.clozure.com)
Otherwise this is the one I would use as it has good Cocoa interoperability.
I'm curious what you mean by a graphical debugger? What can you not do debugging lisp that you can for js/python?
My bad, I mean source-level debugger. Something that allows you to step through forms as they are in the source, unexpanded and not decompiled. It should allow jumping to a line or over an expression, continuing to a point, seamlessly stepping into subroutines, and stepping out of expressions. It would be nice to have single-activation and conditional breakpoints. Variables in the executed portion of the code should be annotated with their values. Sometimes watchers - forms auto-evalled in each frame - are helpful, though these are implemented in some CLs, IIRC. SLY's stickers are close, but they are gathered during execution and replayed later, so the break-edit-recompile-redo workflow doesn't work with them. My experience debugging CL using SBCL and SLIME reminds me of debugging CoffeeScript in a browser before source maps were a thing... It's still 100% doable, just less convenient.
Cool, I'm assuming this is largely driven by mouse usage, as well?
I'm always baffled by how long it has been since I was used to step debugging. It was definitely something that was huge when I was learning, but seemed to get left behind by so many practices.
My general memory is that it was growing and the likes of JRebel were aiming for very powerful uses of debugger connected development experiences. Eclipse, as I recall, have their own compiler specifically to let you debug code that isn't completed. Then, cloud technologies largely came and many just lost track of what could be done.
A fun example, I remember senior engineers at Amazon that didn't know you could hot patch Java while step debugging. Something that they had largely never had a chance to do, because of the standard deployment processes they had been used to.
To the direct point, I am somewhat surprised these aren't doable in Common Lisp. I saw examples showing these years ago, just without the GUI affordances that were in some of the other IDEs. https://malisper.me/debugging-lisp-part-5-miscellaneous/ has examples of the trace command offering conditional breaks and such. Sounds like there is the functionality, but lacking the visual cues/affordances?
> Sounds like there is the functionality, but lacking the visual cues/affordances?
Yeah, some things are missing (arbitrarily moving control to a given line (even if it precedes the current one) in a function, stepping into some functions[1]), but mostly they're there, just clunky to access and view. It's getting better, though - I checked the cookbook page[2] and found a project[3] that I didn't notice previously, which should help quite a bit with convenience. Even with that, though, LispWorks[4] still looks better... ;)
[1] The ones compiled with a low `debug` setting; they're either impossible to step into, or you land in the decompiled source. Trying to step into a function call should recompile that function automatically with debug instrumentation enabled.
[2] https://lispcookbook.github.io/cl-cookbook/debugging.html
[3] https://github.com/mmontone/slime-breakpoints
[4] https://www.lispworks.com/images/lw-ide-cocoa.png
One of the reasons I kept around Java and .NET ecosystems on my toolbox, regardless of their lack of coolness by modern coffee shop coding standards, is exactly the traces of Smalltalk/Lisp development experience that somehow are part of the tooling and runtime capabilities.
By the way, it is relatively easy to plug a debugger into a running container in a Kubernetes pod.
Yeah too many folks pretending their systems are UNIX in 1980's, and not aware of what is available.
I frequently try to mention how Java with JRebel is the closest to the Lisp experience I've found with non-Lisp, it's more dynamic feeling than so-called dynamic languages. Having something like the condition system being ubiquitous would be golden. (I'm aware there is a Java port though I never got around to playing with it and it doesn't solve the problem of other people's code not using it..) My last big job involved a giant app server that would take minutes just to restart if you had to do it, JRebel saved so much time by making things much more reloadable including support for a lot of other libraries' quirks and in general a lot of Java-isms like things configured with XML. Looking under the hood at the JVM you can see traces of Lisp everywhere, like class loaders are just (load)s, it's easy to believe the quote about dragging C++ programmers halfway to Lisp.
Then there's things like rr (https://rr-project.org/) that also seem largely ignored by old unix systems people, despite being exactly appropriate for that environment.
Still, having the whole language available via REPL as Lisp does when you hit a break or error makes up for a lot of weaknesses in the rest of the debugging experience.
I haven't met the individuals like taeric but I do find it plausible that something has been lost for developers whose main experience is in highly separated cloud-oriented systems, whether they go as far as micro-services or not. When you don't have full end-to-end debugging and have to correlate everything with trace ids in logs, and also if policies prevent even getting a debugger hook in production, I can see how one would be less motivated to learn about debugging tools to begin with. (On the other hand you're encouraged to have better logging, and often that's enough to figure out a problem, no need to have a running application.)
Most of the stuff like class loaders came from the Objective-C influence, which naturally has its influences in how Smalltalk and Interlisp-D influenced each other work at Xerox PARC.
JAR files and related structure, are basically redressed NSBundle packages.
Agreed on your last paragraph. Really all of your post. I would oddly find myself arguing against people trying to make a complicated step debug mock setup to simulate the deployed environment when looking for bugs. A general socratic approach to the behavior you were witnessing was a valuable way to find bugs.
To me, the connected debugger was far more interesting as a development tool than a debugging one. Despite the name.
I think the 1980s probably had higher debugger use than today. :)
I was specifically thinking of things like Cloudflare Functions and AWS Lambda, for the deployments that you can't really step debug. They both have ways, nowadays; but nothing that would let you do a hot patch to fix anything.
Granted, my example of senior engineers would be odd there. They definitely were deploying code as standard jar files to machines. Not sure why they didn't know of this. Even the more complicated war files were straight forward to connect to.
Further granted that this isn't something you could realistically do to a fleet of machines. Guessing that is why they didn't ever try to use it.
Depends, Azure definitely has the integrations needed for modern debugging.
With application insights and event tracing, that can be event plugged and debugged postmortem on Visual Studio.
Java world has similar ways with JMX, Visual VM and JFR.
Another great one on part with these two for distributed computing are Erlang based systems.
Finally we have language agnostic ways to do similar workflows based on open telemetry, even if code reload is not part of it.
Step debugging is the hello world version of how to use a debugger.
Agreed that step debugging is the hello world, but I still think it is a better development tool than it is a bug finder.
I'd love to start celebrating more use of these, if you have recommended articles to spread exposure to.
I think a recent update (March 3rd, version 2.5.3) to SBCL added this sorta breakpoint debugging functionality. Hopefully we'll see it integrated with SLIME soon.
> enhancement: breakpoint debugger commands have been added. Included is a stepper based on breakpoints requiring no extra instrumentation. However, it still has less functionality than the existing single stepper. See the new debugger manual section titled "Breakpoint Commands" for more information on the new commands.
For clojure, you can use quil:
https://github.com/quil/quil
I’ve been using quil as I work through _The_Nature_of_Code_ by Daniel Shiffman:
https://natureofcode.com
Processing is what ignited my passion for programming and Quil has become my favorite way of writing it. It is amazing that you can re-evaluate the draw/update function in a running sketch and immediately see the changes, without having to reload the whole thing. And on top of it you have the beauty of the whole Clojure Stdlib with its immutable datastructures.
I just learned that there is now a tweak mode in Processing that lets you tweak certain parameters in the code (via draggable values, etc.) while the sketch is running, which is pretty awesome for experimenting with values. However, you still have to reload the whole sketch when you want to change other parts of the code, you can’t just eval a function in the editor and get immediate feedback like in Quil.
Are you just mentally switching over from their code examples to Quil, or?
If you mean translating from the JavaScript, yes. Quil wraps Processing. Quil did not wrap the vector library (P5.Vector) but most of vector operations are pretty easy to write in base clojure or you can use clojure.matrix. The fun(ctional)-mode lines up with passing initial state through the functions, which clojure makes easy.
This reminds me of the excellent CEPL library (https://github.com/cbaggers/cepl). You can write live shader like programs with cepl with an OpenGL backend.
The author also streamed hours and hours of content using it to make increasingly complicated programs:
https://www.youtube.com/watch?v=I0kWZP9L9Kc
Wonderful CL channel in general.
Baggers is also the author of SLIME: The Superior Lisp Interaction Mode for Emacs, too right?
Among the plethora of strong suits that Common Lisp brings along, the live coding is hands down the best part of it. There is just no better way to experience programming than that.
Sure, the condition system is awesome, CLOS is next to nothing, but the live coding just wins al the way. All the other aspects are just icing on the cake for me.
slightly related, i've been following this game called replicube (https://store.steampowered.com/app/3401490/)
this is livecoding 3d voxel to solve puzzles. the demo was fun. looks like it'll be released soon.
The trailer for that is my nightmare - writing hyper specific if statements everywhere to handle a million edge cases.
Reminds me of something from like 2007ish(?)~ called (fluxus). It was a lisp text editor with a render target in the background and some nice standard library for making 3d objects appear or sfx play. Everything was constantly evaluating/hotloading in the background.
So much fun, I can't find any of the videos in a quick search, so maybe lost to time. Great performative lisping in them hills though.
EDIT: I did find the old page on the wayback machine. https://web.archive.org/web/20120810224932/http://www.pawfal...
Working on a largeish typescript node project right now and no support for recompiling a single function in a live system means I have a good minute of downtime on every change. The lisp paradigm would be so refreshing here.
You could always use regular JS and have that...
1) over my dead body and 2) it doesn’t make sense for it to be possible in JS and not possible in TS.
2) I thought the issue was compilation from TS -> JS. So what's the issue? I remember live coding in JS like 15 years ago, have dev environments just gotten weird and convoluted?
No idea. My working theory is the gotta go fast folks at v8 don’t care about live hot reload because that doesn’t give them ad revenue, so they just wontfixed the whole thing and there is no alternative on the backend if you want typescript.
This doesn't make sense because you can definitely do live coding in Chrome devtools (which uses V8 of course) and in Nodejs (--watch will reload code changes automatically and there's ways to keep application state through code changes).
Edit - can also apparently do it with TS directly with Deno (also V8), here's an example: https://dev.to/craigmorten/how-to-code-live-browser-refresh-...
I’ll be very happy to be wrong here! Looking at these, thanks
Love this. Sketch, in particular, looks really exciting to me. I'll have to take a look into trying it out. I still have dreams of doing some of the ideas in Turtle Geometry on a modern computer.
I am not sure if this is what you mean, but the original UCBLogo (which I think is used in the Turtle Geometry book) is still alive and maintained[1] (not by the original authors, but Brian Harvey seems to chime in every now and then) and it does run well on modern computers.
Now that I think about it, Logo seems to be pretty much a livecoding environment (not surprising given that it is a Lisp, but with less parentheses). You can define and edit functions from the REPL while the program continues with the same state, the same canvas. You can even pause e.g. a running procedure that draws a polygon, rotate and move the turtle and then continue the polygon procedure with that new state (at least this is possible with UCBLogo).
[1]: https://github.com/jrincayc/ucblogo-code
It is indeed what I had in mind, I was amusingly ignorant that this was being maintained. Humble apologies on my end! Edit: And thanks for correcting me!
This sounds like a great developer experience, but the path from live-coded LISP graphics to a game that can be made public on ie. Steam is a long and troublesome path, compared to using for example OpenGL and C++.
I wish more programming languages focused on quick compilation times, easy cross compilation and straightforward deployment in general.
What makes it so much harder to publish a CL game on Steam versus a C++ game?
Well, for starters, how do you add cross-compilation to Linux, macOS and Windows to something like this using ie. SBCL?
https://github.com/xyproto/sdl2-examples/blob/main/lisp/Make...
dang, livecoding always gets me fired up - i mess around with this kind of stuff too, nothing beats seeing changes instantly