4 ms·
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 mathemati
by susam 2y ago
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 https://github.com/susam/susam.net
[2] https://github.com/susam/mathb https://github.com/susam/mathb
- klibertp 2y agoI 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 2y agoCMUCL has a graphical debugger.
- pasc1878 2y agoUnfortunately it looks like only if you are running X11 which cuts most people out.
- guenthert 2y agoThat 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).
- pasc1878 2y agoUnfortunately CCL is Intel only on macOS. (macOS is not on the the main page https://ccl.clozure.com https://ccl.clozure.com) Otherwise this is the one I would use as it has good Cocoa interoperability.
- vindarel 2y agofor folks looking for libraries: https://github.com/CodyReichert/awesome-cl/ 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/ https://github.com/coalton-lang/coalton/ for a Haskell on top of CL now)
- tmtvl 2y ago