[HN Gopher] Graphics livecoding in Common Lisp
___________________________________________________________________
Graphics livecoding in Common Lisp
Author : adityaathalye
Score : 84 points
Date : 2025-04-23 17:48 UTC (5 hours ago)
(HTM) web link (kevingal.com)
(TXT) w3m dump (kevingal.com)
| jasonjmcghee wrote:
| 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.
| adityaathalye wrote:
| 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
| dang wrote:
| 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.
| swah wrote:
| 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!
| Arcanum-XIII wrote:
| 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!
| chaosprint wrote:
| 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/
| J_McQuade wrote:
| 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!
| jasonjmcghee wrote:
| Excited to spread the brain worm. Don't hesitate to join in
| the fun / log issues / contribute / share how you use it!
| taeric wrote:
| 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.
| phforms wrote:
| 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
| taeric wrote:
| 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!
| z3phyr wrote:
| 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.
| gen_greyface wrote:
| 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.
| baq wrote:
| 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.
| dismalaf wrote:
| You could always use regular JS and have that...
| baq wrote:
| 1) over my dead body and 2) it doesn't make sense for it to
| be possible in JS and not possible in TS.
| dismalaf wrote:
| 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?
| baq wrote:
| 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.
| dismalaf wrote:
| 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-...
| susam wrote:
| 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
| klibertp wrote:
| 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.
| rjsw wrote:
| CMUCL has a graphical debugger.
| gitroom wrote:
| dang, livecoding always gets me fired up - i mess around with
| this kind of stuff too, nothing beats seeing changes instantly
| kailden wrote:
| 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
___________________________________________________________________
(page generated 2025-04-23 23:00 UTC)