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!
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)
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.
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 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)
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.
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.
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!
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.
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!
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)
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!
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/
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.
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)
CMUCL has a graphical debugger.
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.
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?
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-...
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!
dang, livecoding always gets me fired up - i mess around with this kind of stuff too, nothing beats seeing changes instantly
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.