vindarel
1 HN recommender · recommended in 10 months, 2023–2025
4:46 · 5.3K views · Dec 5, 2022
A five-minute demo of the Common Lisp debugger fixing a bug, recompiling a single function, and resuming execution from the failed stack frame. It shows how to avoid re-running long computations.
HN Lisp fans repeatedly link it as a short, concrete demonstration of Common Lisp's interactive debugging advantage.
12 comments from Hacker News
To really discover what interactive, image-based CL development is about, my pointers: - this video (5min) my demo to show how to resume execution of a long running program, from the stack frame right before the bug, after having fixed and recompiled the function, without quitting the debugger hence without stopping the program, thus without restarting everything from zero. - [LINK] (20min)showing what saving and restoring an image does, differences between SBCL and LispWorks. - [LINK] developing a 3D graphics software. - [LINK] - debugging CL tools: [LINK] - and no: while we could deploy a ball of mud to production, we can also not and use traditional tools and techniques: build an executable from scratch, restart the app, reload state. But we can do everything in between too (inspect the running app, change it a bit, change it a whole lot (while staying in sync with local source code), use images to speed-up development etc).
false premises, false conclusions, and bad good ideas in-between. > I was surprised by the absence of a quickstart page to help me set up a simple server what about [LINK] ? Also I think that the READMEs of Mito (ORM) and Djula (templating) and easy-routes (routing) are very good. Heck, Djula's documentation is excellent. Double heck, even Caveman's README, which the author uses, has a good and sufficient getting-started page. Oh, I understand, the author uses Clack/Lack… where Hunchentoot is much better documented. there are of course more blog posts, some videos. I invite any blogger to consolidate community resources. More recent: [LINK] ps: > ;; If the template is not already compiled, it is compiled, and stored in TEMPLATE-REGISTRY . won't that prevent the template to compile changes? I suggest to follow Djula's doc. > I would add a way to invalidate the cache automatically if a template changes. yeah. So don't do that ;) (also +1 to Jach's remarks and explanations) > I created a macro that ensure the table gets created correctly hummm… I'd suggest to leave the migration step explicit. > some database helpers to perform a few CRUD actions on the db. I felt the need for CRUD helpers too when defining Mito classes. However those four ones are only similar functions with same parameters but another name :] (defun db-add (instance) "Inserts a model instance into the database." (insert-dao instance)) > I would say that there are better languages for developing modern web apps
> all the other languages have kept picking up nearly everything once-cutting-edge about Lisp not all of them have CL's set of features: excellent long-live REPL, image-based development, compiling to binaries, the condition system, the interactive debugger and excellent developper tools (resumable stack frames, never re-run a long operation from zero [1]), the whole language at compile-time, stable syntax, extensible syntax, stable ecosystem, fast implementations, numeric tower, first-class interop to Java (LispWorks, ABCL), commercial support, mobile platforms delivery (LispWorks)… New CL implementations get created (CLASP, CL on C++ with LLVM or NPT, in C) and CL compilers and libraries evolve too [2]. SBCL is now callable as a shared library, it got a SIMD module, rumors say a bear party after ELS 2024 escalated and that they are adding coroutines soon. ECL is targetting WASM, all other major implementations had new releases. New libraries unlock new possibilities (Coalton: Haskell-like typing on top of CL), companies still pick CL today (CL is all the rage in quantum computing?), the community creates more resources and more tools such as, last but not least, new editor plugins o/ [LINK] (VSCode, Pulsar, Jetbrains, Sublime, Jupyter… Lem of course etc) [1]: this video [2]: [LINK]
> lots of interoperability libraries That's true. For cases when you want to start with a good set of libraries (json, csv, databases, HTTP client, CLI args, language extensions…), I am putting up this collection together: [LINK] It can be used as a normal Quicklisp library, or as a core image (it then starts up instantly) or as a binary. It can run scripts nearly instantly too (so it isn't unlike Babashka). We are ironing out the details, not at v1.0 yet. > handling a runtime error by just fixing the broken code--in-place, without any restarts [from the blog] Also (second shameless plug) I should have illustrated this here: this video We run a long and intensive computation and, bad luck, we get an error in the last step. Instead of re-running everything again from zero, we get the interactive debugger, we go to the erroneous line, we compile the fixed function, we come back to the debugger, we choose a point on the stackframe to resume execution from (the last step), and we see our program pass. Hope this illustrates the feature well!
I suggest: do you find yourself often quitting the debugger and re-running the same test, the same task from the start? You can avoid that in CL. Just leave the debugger open, go to the buggy line ("v" on a stacktrace in Slime), fix the function, re-compile it on the fly (C-c C-c in Slime), come back to the debugger, resume the program from the stackframe you want, now it passes. If the first steps were taking 10 minutes, you just saved yourself some time. You don't need special needs for that, it's a fast workflow I use everyday. demo: this video debugging a complex stacktrace: Python VS CL: [LINK] Another important point: we debug everything while keeping the current state in memory (in the image). We don't have to re-create our test data. All the program state is kept live, until we restart the image.