5 ms·

Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. Smalltalk is som

Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. Smalltalk is something like the ultimate debugger. The advanced Smalltalk coders would often do most of their coding in the debugger. (It's very easy to unwind the stack a few places, then resume execution.) The VisualWorks debugger was so nimble, people would put expressions to be executed and debugged into code comments! (The debugger would execute the code in the context in which it was evaluated, so this could be absolutely awesome.) Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else’s!) will break, and it will break often, and you’ll get launched into an interactive debugger. One of the most frequent demos we did in Smalltalk, was to write some empty scaffold methods, launch into an exception, then fill in everything in the debugger until the system was complete.

ben509 8y ago
I think direct language support for "missing code here!" is a brilliant idea. Even when you have types and documentation, you often need to dummy check that values you'll get called with are what you expect.
- corysama 8y ago
  I've heard Smalltalkers tell tales of starting an empty project by just hitting "Run", letting the debugger take exception to that fact that there is no startup function, then start typing code as it becomes necessary to proceed.
  - stcredzero 8y ago
    That's what I just wrote!
    - traviscj 8y ago
      I read the GP as saying “you don’t even need to create the scaffold methods” described in your post.
lispm 8y ago
> It's very easy to unwind the stack a few places, then resume execution That's what some Lisp systems do, too. > The debugger would execute the code in the context in which it was evaluated, so this could be absolutely awesome That's what Lisp debuggers would do, too. > launch into an exception, then fill in everything in the debugger until the system was complete. That's actually an old story about Marvin Minsky: --- Here's an anecdote I heard once about Minsky. He was showing a student how to use ITS to write a program. ITS was an unusual operating system in that the `shell' was the DDT debugger. You ran programs by loading them into memory and jumping to the entry point. But you can also just start writing assembly code directly into memory from the DDT prompt. Minsky started with the null program. Obviously, it needs an entry point, so he defined a label for that. He then told the debugger to jump to that label. This immediately raised an error of there being no code at the jump target. So he wrote a few lines of code and restarted the jump instruction. This time it succeeded and the first few instructions were executed. When the debugger again halted, he looked at the register contents and wrote a few more lines. Again proceeding from where he left off he watched the program run the few more instructions. He developed the entire program by `debugging' the null program. --- One of the main debugging differences between Lisp and Smalltalk though is that Lisp systems often can run interpreted Lisp code (where Smalltalk runs bytecode) and then the debugger can see and change the actual source code while it is running. A Lisp Interpreter runs of Lisp source code - which still is data, since in Lisp source = structured data. Useful Lisp debugging experiences existed as early as late 60s / early 70s in BBN Lisp. http://www.bitsavers.org/pdf/bbn/tenex/TenexLispRef_Aug72.pdf http://www.bitsavers.org/pdf/bbn/tenex/TenexLispRef_Aug72.pd... The BBN Lisp development then moved to Xerox PARC and was renamed to Xerox Interlisp.

ben509 8y ago

I think direct language support for "missing code here!" is a brilliant idea. Even when you have types and documentation, you often need to dummy check that values you'll get called with are what you expect.

corysama 8y ago
I've heard Smalltalkers tell tales of starting an empty project by just hitting "Run", letting the debugger take exception to that fact that there is no startup function, then start typing code as it becomes necessary to proceed.
- stcredzero 8y ago
  That's what I just wrote!
  - traviscj 8y ago
    I read the GP as saying “you don’t even need to create the scaffold methods” described in your post.

lispm 8y ago

> It's very easy to unwind the stack a few places, then resume execution That's what some Lisp systems do, too. > The debugger would execute the code in the context in which it was evaluated, so this could be absolutely awesome That's what Lisp debuggers would do, too. > launch into an exception, then fill in everything in the debugger until the system was complete. That's actually an old story about Marvin Minsky: --- Here's an anecdote I heard once about Minsky. He was showing a student how to use ITS to write a program. ITS was an unusual operating system in that the `shell' was the DDT debugger. You ran programs by loading them into memory and jumping to the entry point. But you can also just start writing assembly code directly into memory from the DDT prompt. Minsky started with the null program. Obviously, it needs an entry point, so he defined a label for that. He then told the debugger to jump to that label. This immediately raised an error of there being no code at the jump target. So he wrote a few lines of code and restarted the jump instruction. This time it succeeded and the first few instructions were executed. When the debugger again halted, he looked at the register contents and wrote a few more lines. Again proceeding from where he left off he watched the program run the few more instructions. He developed the entire program by `debugging' the null program. --- One of the main debugging differences between Lisp and Smalltalk though is that Lisp systems often can run interpreted Lisp code (where Smalltalk runs bytecode) and then the debugger can see and change the actual source code while it is running. A Lisp Interpreter runs of Lisp source code - which still is data, since in Lisp source = structured data. Useful Lisp debugging experiences existed as early as late 60s / early 70s in BBN Lisp. http://www.bitsavers.org/pdf/bbn/tenex/TenexLispRef_Aug72.pdf http://www.bitsavers.org/pdf/bbn/tenex/TenexLispRef_Aug72.pd... The BBN Lisp development then moved to Xerox PARC and was renamed to Xerox Interlisp.