5 ms·

I find the distinction between step debugging and runtime debugging to be more useful. Someone who steps through every line of code will probably take longer t

I find the distinction between step debugging and runtime debugging to be more useful. Someone who steps through every line of code will probably take longer to find the bug, and will spin cycles on rabbit holes and false paths. Someone who uses “runtime debugging”, or rather has a hypothesis on the bug or what a piece of code is doing and uses a debugger or print statement to verify that will find the bug much quicker. With this mental model, you can see how print statements can be as effective as a debugger in many scenarios.

thirtyfivecent 4y ago
Totally agree. Print statements are windows to the programs internal state. They can be activated during specific times, under certain conditions, can group together information and values.... The name "print statement" does not do them justice , that is the problem i think, they are a conduit, a channel of symbols for peeking into the program
- josteink 4y ago
  So can a debugger, except when you find something unusual, a real debugger will allow you to inspect things you didn't consider instrumenting, change variable-values, re-run code and validate assumptions. I just don’t see where this skepticism against specialised tools for tracking down bugs comes from.
  - Dudeman112 4y ago
    >I just don’t see where this skepticism against specialised tools for tracking down bugs comes from Probably from the previous skepticism against print debugging. Every prevalent strong opinion in a social setting is eventually met with an equally strong opposite opinion in the same social setting.
dexwiz 4y ago
If your runtime is in any sort of framework, step debugging often drops you into framework code that you never look at that exists between your logic. This is my biggest hang up when trying to step debug beyond a single method or class.
- lpapez 4y ago
  Most of the debuggers I ever tried have a "Debug my code only" option or something similar and they usually work well (even for C/C++ where you can specify paths to ignore). Have you tried those?
- rcxdude 4y ago
  "Step over" (stepping over a function call without going into it) and "Step out" (step until the current function returns) are your friends here.

thirtyfivecent 4y ago

Totally agree. Print statements are windows to the programs internal state. They can be activated during specific times, under certain conditions, can group together information and values.... The name "print statement" does not do them justice , that is the problem i think, they are a conduit, a channel of symbols for peeking into the program

josteink 4y ago
So can a debugger, except when you find something unusual, a real debugger will allow you to inspect things you didn't consider instrumenting, change variable-values, re-run code and validate assumptions. I just don’t see where this skepticism against specialised tools for tracking down bugs comes from.
- Dudeman112 4y ago
  >I just don’t see where this skepticism against specialised tools for tracking down bugs comes from Probably from the previous skepticism against print debugging. Every prevalent strong opinion in a social setting is eventually met with an equally strong opposite opinion in the same social setting.

dexwiz 4y ago

If your runtime is in any sort of framework, step debugging often drops you into framework code that you never look at that exists between your logic. This is my biggest hang up when trying to step debug beyond a single method or class.

lpapez 4y ago
Most of the debuggers I ever tried have a "Debug my code only" option or something similar and they usually work well (even for C/C++ where you can specify paths to ignore). Have you tried those?
rcxdude 4y ago
"Step over" (stepping over a function call without going into it) and "Step out" (step until the current function returns) are your friends here.