Debugging Lisp (2015)(malisper.me) |
Debugging Lisp (2015)(malisper.me) |
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.
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.)
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."
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.
C-u C-c C-k ;; recompile with (debug 3)
(step (some-function))
Compare this to another project I've been working on which is written in Kotlin. Almost every debugging session involves a lot of single-stepping.
There is no insightful point of this reply, except for agreeing that Lisp is powerful enough that single-stepping is mostly pointless. I do add a lot of (break) statements during debugging though.
Mind you, with python you can at least run things with ipython --pdb to get thrown into a debugger on failure so you can potentially serialize some state before losing it. And stacktraces are better than common lisp's. But having a robust way to redefine stuff or fixing up a failed computation is definitely very handy in some contexts.
When I learned CL, the condition/restart system and pervasive hot code reloading reminded me of my Python hack and how much easier it would have been in a language designed for this sort of programming.
It was amazing.
But JRebel is still fundamentally an incomplete solution because of the way it handles (or fails to handle) existing instances. In practice you learn to live with it, designing for more static methods or short-lived objects so the next time a code path runs it'll be with new objects and new code, or you bite the restart bullet for the times when you have a long-lived object that you need to change and it's important that it uses the new code and data. Those times are typically rarer, admittedly, and so most of the benefit is captured by being able to redefine classes and methods (and functions in Lisp) more-so than updating existing instances, but it's great that Lisp supports the latter when you need it.
The context matters, though. I've been working with Lisp systems (and occasionally with Smalltalk systems) for over thirty years, and the way I normally work is to start with some simple sketch of a model and some simple interactions with it, and build it up gradually, interactively. While my program runs, of course.
That means making a lot of incremental changes to the model as I go, which, in a class-based system, means a lot of changes to classes. And since I prefer to modify my work while it runs, that means a lot cases of the environment saying, "hey, this definition changed; what do you want to do about it?"
If you typically work in an environment that doesn't support those kinds of incremental changes to a running system, then of course you're going to learn a way of working where such situations don't come up, because they can't.
Your question about not needing to restart the runtime ("how often do you have to do this?") seems to imply that you expect the common answer to be "(almost) never" -- that expectation is not surprising since most languages don't even support this kind of debugging!
That's exactly the point of the author: to demonstrate a different way of debugging that's afforded by Lisp and to demonstrate that it can be incredibly powerful. It's just something that is perhaps unfamiliar to programmers who are more used to other programming languages where the debugging facilities are different.
Stack traces are not standardized in Common Lisp, so this is a non-sensical statement. At worst you could say that Python's stack traces are better than some particular CL implementation, but not CL in general.
And almost certainly, if you don't like the way your CL presents stack traces, you can easily change it.
Yes, someone could have secretly implemented a common lisp implementation that has the most ergonomic stacktraces in the whole wide world or, equally, a posix shell that runs numerical code a gazillion times faster than the equivalent C compiled with gcc -O3 -mnative -ffast-math because after all the relevant standards do not explicitly forbid it!
I'm not quite sure why lispers in particular are so in love with this argument.
There is nothing nonsensical in saying that shell is a truly terrible language to write high performance numerical code in, even if that is not true by some sort of logical necessity.
In practice most languages have a dominant implementation (even those with ISO standards) and a range of capabilities that existing (and likely future) implementations fall within. Both are far more important than what standards say (try compiling code with djb's standard conformant usage of errno some time).
This is ipython:
In [2]: os.path.join(None)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-2-ba05fdaae739> in <module>
----> 1 os.path.join(None)
/opt/anaconda3/lib/python3.8/posixpath.py in join(a, *p)
74 will be discarded. An empty last part will result in a path that
75 ends with a separator."""
---> 76 a = os.fspath(a)
77 sep = _get_sep(a)
78 path = a
TypeError: expected str, bytes or os.PathLike object, not NoneType
* (merge-pathnames nil)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1000560083}>:
The value
NIL
is not of type
(OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME SYNONYM-STREAM
FILE-STREAM)
when binding PATHNAME
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(MERGE-PATHNAMES NIL 70256781343884 MERGE-PATHNAMES) [external]
0]
SBCL told you that the call to MERGE-PATHNAME is already wrong. A backtrace then will only show higher up code from the environment and the call to MERGE-PATHNAME.
Your Python code went into the routine...
Often the Python backtrace will be easier to understand, since it is source/line oriented, since Python code usually does not have extensive code transformations (-> Lisp macros) and using an optimizing compiler like SBCL may make the code less debuggable (for example when using tail call optimization).
* (merge-pathnames nil)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {10010B0523}>:
The value
NIL
is not of type
(OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME SYNONYM-STREAM
FILE-STREAM)
when binding PATHNAME
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.
(MERGE-PATHNAMES NIL 4946604 MERGE-PATHNAMES) [external]
0] :backtrace
Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {10010B0523}>
0: (MERGE-PATHNAMES NIL 4946604 MERGE-PATHNAMES) [external]
1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (MERGE-PATHNAMES NIL) #<NULL-LEXENV>)
2: (EVAL (MERGE-PATHNAMES NIL))
3: (INTERACTIVE-EVAL (MERGE-PATHNAMES NIL) :EVAL NIL)
4: (SB-IMPL::REPL-FUN NIL)
5: ((FLET "LAMBDA0" :IN "SYS:SRC;CODE;TOPLEVEL.LISP"))
6: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<CLOSURE (FLET "LAMBDA0" :IN "SYS:SRC;CODE;TOPLEVEL.LISP") {96F7CB}>)
7: (SB-IMPL::TOPLEVEL-REPL NIL)
8: (SB-IMPL::TOPLEVEL-INIT)
9: ((FLET SB-UNIX::BODY :IN SAVE-LISP-AND-DIE))
10: ((FLET "WITHOUT-INTERRUPTS-BODY-7" :IN SAVE-LISP-AND-DIE))
11: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))
12: ("foreign function: #x43270B")
13: ("foreign function: #x403F08")
0] The value
NIL
is not of type
(OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME
SYNONYM-STREAM FILE-STREAM)
when binding PATHNAME
[Condition of type TYPE-ERROR]
Restarts:
0: [RETRY] Retry SLY mREPL evaluation request.
1: [*ABORT] Return to SLY's top level.
2: [ABORT] abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1004894CD3}>)
Backtrace:
0: (MERGE-PATHNAMES NIL 69988797066848 MERGE-PATHNAMES) [external]
1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (MERGE-PATHNAMES NIL) #<NULL-LEXENV>)
2: (EVAL (MERGE-PATHNAMES NIL))
3: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1))
--more--
However, as I wrote common lisp is much nicer in some other respects (as you undoubtedly know). For a few other toy examples let's say I do:
(/ 1 (random 2))
(mapcar #'sine '(1 2 3))
The function COMMON-LISP-USER::SINE is undefined.
[Condition of type UNDEFINED-FUNCTION]
Restarts:
0: [CONTINUE] Retry using SINE.
1: [USE-VALUE] Use specified function
[...]
This is pretty cool, because it means you can start writing some topdown code start running it an incrementally fill in the missing functions you are calling bad haven't yet defined without ever losing your state.
No, you do get that. Even in the plain python interpreter you can do import pdb; pdb.pm() after an error to do post mortem debugging and walk up and down the stackframes and inspect or manipulate local variables. In ipython that happens automatically (if you run with --pdb) or after you type `debug` after an exception. And tooling for production stacktraces normally also captures local variables.
There are a bunch of additional niceties that Common Lisp has, such as turtles-most-of-the-way-down: you might eventually hit a foreign function call you cannot further inspect, but for most Common Lisp implementations almost everything is implemented in lisp. In python you a significant proportion are C extensions which are opaque to the built in debugger, although you can make gdb work. Also remote debugging is much more natural in common lisp.
Generally the stuff that is better about the debugging experience in python is in a way more superficial and the stuff that's nicer in common lisp is much more fundamental, and yet, my experience is different than yours: the superficial stuff that python does well and common lisp does badly or simply less well matters more for overall productivity for most things I tend to do. This is although the debugger related stuff you can't do as well with common lisp amounts more or less to minor friction whereas the stuff you can't do with python is really hard to work around if you need it.
I think this is an object lesson on focussing on the (right) low hanging fruit.