Warning: a bit of a shameless plug.<p>I have recently given an interview[0] for Immutable Conversations where I show some of the techniques described in these blogposts. In the video, inspect the state of the Lisp image, and I evaluate arbitrary code (redefining functions and variables) while not leaving the debugger. Perhaps HN can find this interesting, as it is a livecoding demonstration of how a Lisp programmer might make use of these techniques in real-life scenarios.<p>The examples are trivial and might be perhaps a bit too trivial for people used to programming, but the secondary point of the video was to demonstrate the livecoding techniques to people who possibly do not know Lisp whatsoever, and I didn't want to burden them with complicated code examples. (The primary point was to describe the Common Lisp condition system, which I have written a book[1] about, and show the basics of control flow in Common Lisp that are the foundation of conditions.)<p>[0] <a href="https://www.youtube.com/watch?v=pkqQq2Hwt5o" rel="nofollow">https://www.youtube.com/watch?v=pkqQq2Hwt5o</a><p>[1] <a href="https://news.ycombinator.com/item?id=24867548" rel="nofollow">https://news.ycombinator.com/item?id=24867548</a>
I now have a good place to link to when talking about lisp debugging being the killer feature that keeps me coming back to lisp as a language.<p>I usually get very confused responses when I say this, as people think "single step through the code" when I say "debugger" and I respond with something like "I'm pretty sure there's a way to step through the code in SLIME, but I never learned it because I've never had a need for that."<p>A quick skim through the series shows that the author feels the same way; there doesn't seem to be a mention of SLDB's stepper.