4 ms·

During debugging, yea?

phoe-krk 6y ago
Yes, all that without leaving the debugger. The debugger is left only when we want to continue execution of the program.
- protomyth 6y ago
  I've noticed quite a few Smalltalk programmers who actually coded in the debugger. They would put a call in the program, hit it as an error, and then write new code. Does this happen with Common Lisp programmers?
  - phoe-krk 6y ago
    Smalltalk and Common Lisp are both image-based programming languages where the compiler and debugger are always available. I think debugger-oriented programming is much more common in Smalltalk than in Lisp (at least I prefer to leave the debugger back to REPL pretty often), but I think it's certainly possible to adopt. The Slime/Sly environments for emacs might accept a few patches to facilitate that programming style better.
  - p_l 6y ago
    I know of several lispers that swear by top-down "programming inside debugger", where they continuously fill in the gaps starting from top level function :-D
    - phoe-krk 6y ago
      Do you have any videos of such programming style performed in Lisp, or could you try to convince some of those programmers to record some of their programming sessions?
      - rags2riches 6y ago
        You could look up Baggers on Youtube for plenty of fun Lisp coding sessions.
        phoe-krk 6y ago
        I know Baggers and his videos but I wasn't aware that he does debugger-oriented programming. Thanks, I'll pay closer attention to them!
aidenn0 6y ago
For this example, it would be during debugging. You could intentionally write a bug, and then write a condition handler that would fix the bug without unwinding the stack further than necessary, but that would be rather pointless. However think of all the things that can go wrong with your environment that don't involve a bug in your program. A network connection goes down, the disk gets full, &c. All of those can be handled without unwinding the stack to the point where the code for handling them was defined. For a really trivial example, consider a performance watchdog. If you want to completely abort the attempt and log a call-stack, you can do that it just about any modern, dynamic language because the exception object includes the call-stack. But what if you want to log the call-stack and continue for the first N times the watchdog rolls-over? This is, of course, doable in other languages with passing callbacks and such, but in Lisp this can be done by signalling a condition in the exact same manner that an exceptional condition would be signaled. I'm excited about this book, because that particular feature is underutilized in Lisp (by myself included), probably because it's one of the last dynamic things that Lisp does that more well-known dynamic languages do not, so programmers coming from other languages just aren't going to use it.
- phoe-krk 6y ago
  > All of those can be handled without unwinding the stack to the point where the code for handling them was defined. Nitpick: the only thing that cannot be handled by winding the stack is when you run out of stack to wind. But, luckily, if your program overflows the stack, you usually have bigger issues to deal with and/or you usually have all the stack information you need to diagnose the problem.

Yes, all that without leaving the debugger. The debugger is left only when we want to continue execution of the program.

protomyth 6y ago
I've noticed quite a few Smalltalk programmers who actually coded in the debugger. They would put a call in the program, hit it as an error, and then write new code. Does this happen with Common Lisp programmers?
- phoe-krk 6y ago
  Smalltalk and Common Lisp are both image-based programming languages where the compiler and debugger are always available. I think debugger-oriented programming is much more common in Smalltalk than in Lisp (at least I prefer to leave the debugger back to REPL pretty often), but I think it's certainly possible to adopt. The Slime/Sly environments for emacs might accept a few patches to facilitate that programming style better.
- p_l 6y ago
  I know of several lispers that swear by top-down "programming inside debugger", where they continuously fill in the gaps starting from top level function :-D
  - phoe-krk 6y ago
    Do you have any videos of such programming style performed in Lisp, or could you try to convince some of those programmers to record some of their programming sessions?
    - rags2riches 6y ago
      You could look up Baggers on Youtube for plenty of fun Lisp coding sessions.
      - phoe-krk 6y ago
        I know Baggers and his videos but I wasn't aware that he does debugger-oriented programming. Thanks, I'll pay closer attention to them!

aidenn0 6y ago

For this example, it would be during debugging. You could intentionally write a bug, and then write a condition handler that would fix the bug without unwinding the stack further than necessary, but that would be rather pointless. However think of all the things that can go wrong with your environment that don't involve a bug in your program. A network connection goes down, the disk gets full, &c. All of those can be handled without unwinding the stack to the point where the code for handling them was defined. For a really trivial example, consider a performance watchdog. If you want to completely abort the attempt and log a call-stack, you can do that it just about any modern, dynamic language because the exception object includes the call-stack. But what if you want to log the call-stack and continue for the first N times the watchdog rolls-over? This is, of course, doable in other languages with passing callbacks and such, but in Lisp this can be done by signalling a condition in the exact same manner that an exceptional condition would be signaled. I'm excited about this book, because that particular feature is underutilized in Lisp (by myself included), probably because it's one of the last dynamic things that Lisp does that more well-known dynamic languages do not, so programmers coming from other languages just aren't going to use it.

phoe-krk 6y ago
> All of those can be handled without unwinding the stack to the point where the code for handling them was defined. Nitpick: the only thing that cannot be handled by winding the stack is when you run out of stack to wind. But, luckily, if your program overflows the stack, you usually have bigger issues to deal with and/or you usually have all the stack information you need to diagnose the problem.