4 ms·

Is there anything about this lesson on using the Lispm debugger that you could convey in a comment? I have a Lisp machine myself, and am painfully aware that t

Is there anything about this lesson on using the Lispm debugger that you could convey in a comment? I have a Lisp machine myself, and am painfully aware that there must be a lot of lore that is not adequately documented, and am trying to preserve as much as I can.

gumby 8y ago
I wasn't using the debugger at all, and Gosper showed me what a great tool it was (note: Plauger disagrees). What was great about the Lisp debuggers (MACLISP, MIT lispm, and Interlisp-D were the only Lisp ones I ever used extensively, though I also found this functionality really handy in PARC Smalltalk) is that they were part of the environment so from the debugger (or another window, like your editor, in the case of the Lispm and D machines) you could write little routines to explore the problem and, update a buggy function, and the continue from wherever you wanted in the stack. In this they were like the assembly debuggers, like DDT which was our "shell" on the ITS machines. Compare this to the Unix paradigm where you have to explicitly decide to run under debugging (or at best dredge through a core dump): you often can't really look at what caused the problem since whatever caused it (open files, network connections and the like) are gone; your debugger runs in a different environment (process) from the program you're debugging, and doesn't have the same program affordances, i.e. no programming language. You can't imaging how many people were blown away in the 90s by the ability in gdb to simply call a function in your target program when stopped at a breakpoint. To me that has always been basic functionality. It's rather shocking and frustrating to me that the development environments today are in many ways much more primitive than we enjoyed in the 1970s! I bang my head against the limitations of VScode and Xcode and go back to Emacs which at the end of the day is sadly just as powerful.
- EdwardCoffin 8y ago
  I used Smalltalk for a while, so I at least had this rich debugger experience there: being able to change code whilst halted at a breakpoint and resume with the new code taking effect immediately, no world recompilation needed; being able to compose complicated queries in the debugger to do consistency checking of live data structures I was looking at, stuff like that. The thing is, I did not learn any of that from a book, I had to learn it from someone else who knew it. Thanks for the details, sounds like I need to look at DDT too. I can't remember where I read this, but I think it was about Marvin Minsky, a story about programming in the debugger, where the subject started out with an empty program, ran it which immediately put him in the debugger, and there he just built up the program a statement at a time to handle whatever the program needed to do at the step it was currently at, and it would just dump him to a breakpoint every time it got to a part where he had not yet specified what was to be done. The whole program was eventually composed in one debugging session starting from an empty program. I suspect this must have been done in DDT, or something much like it. Does that sound plausible to you?
  - gumby 8y ago
    It does not sound plausible, TBH. I have a friend who scorns exploratory programming a “programming by successive approximation” a statement which I have to admit has some truth to it. This story sounds like something he might say.
    - EdwardCoffin 8y ago
      I found the reference [1]. I think this style has its place, like when you don't know exactly what you need in general, but can make concrete decisions as you encounter them. Kind of like the rough sketching of programming. I wouldn't want to fly in a plane whose control software was written this way though. [1] http://lambda-the-ultimate.org/node/12 http://lambda-the-ultimate.org/node/12

gumby 8y ago

I wasn't using the debugger at all, and Gosper showed me what a great tool it was (note: Plauger disagrees). What was great about the Lisp debuggers (MACLISP, MIT lispm, and Interlisp-D were the only Lisp ones I ever used extensively, though I also found this functionality really handy in PARC Smalltalk) is that they were part of the environment so from the debugger (or another window, like your editor, in the case of the Lispm and D machines) you could write little routines to explore the problem and, update a buggy function, and the continue from wherever you wanted in the stack. In this they were like the assembly debuggers, like DDT which was our "shell" on the ITS machines. Compare this to the Unix paradigm where you have to explicitly decide to run under debugging (or at best dredge through a core dump): you often can't really look at what caused the problem since whatever caused it (open files, network connections and the like) are gone; your debugger runs in a different environment (process) from the program you're debugging, and doesn't have the same program affordances, i.e. no programming language. You can't imaging how many people were blown away in the 90s by the ability in gdb to simply call a function in your target program when stopped at a breakpoint. To me that has always been basic functionality. It's rather shocking and frustrating to me that the development environments today are in many ways much more primitive than we enjoyed in the 1970s! I bang my head against the limitations of VScode and Xcode and go back to Emacs which at the end of the day is sadly just as powerful.

EdwardCoffin 8y ago
I used Smalltalk for a while, so I at least had this rich debugger experience there: being able to change code whilst halted at a breakpoint and resume with the new code taking effect immediately, no world recompilation needed; being able to compose complicated queries in the debugger to do consistency checking of live data structures I was looking at, stuff like that. The thing is, I did not learn any of that from a book, I had to learn it from someone else who knew it. Thanks for the details, sounds like I need to look at DDT too. I can't remember where I read this, but I think it was about Marvin Minsky, a story about programming in the debugger, where the subject started out with an empty program, ran it which immediately put him in the debugger, and there he just built up the program a statement at a time to handle whatever the program needed to do at the step it was currently at, and it would just dump him to a breakpoint every time it got to a part where he had not yet specified what was to be done. The whole program was eventually composed in one debugging session starting from an empty program. I suspect this must have been done in DDT, or something much like it. Does that sound plausible to you?
- gumby 8y ago
  It does not sound plausible, TBH. I have a friend who scorns exploratory programming a “programming by successive approximation” a statement which I have to admit has some truth to it. This story sounds like something he might say.
  - EdwardCoffin 8y ago
    I found the reference [1]. I think this style has its place, like when you don't know exactly what you need in general, but can make concrete decisions as you encounter them. Kind of like the rough sketching of programming. I wouldn't want to fly in a plane whose control software was written this way though. [1] http://lambda-the-ultimate.org/node/12 http://lambda-the-ultimate.org/node/12