3 ms·

that's called a debugger, put a breakpoint somewhere, the application will pause right there and show you all the variables.

barrkel 6y ago
Funny thing about debuggers is that they seem to encourage stepping - step in, step out, step over, single step, step to return. Stepping is an enormous waste of time with a debugger. Breakpoints are where it's at. Level up your breakpoints: logging breakpoints, conditional breakpoints, memory breakpoints (super handy when combined with deterministic memory allocation), syscall / library breakpoints - and soon you're going somewhere useful. Debugging is about formulating theories and proving them wrong, or right. Stepping doesn't scale; breakpoints can scale, if you know where to put them. I'm not sure that the gap between a debugger with breakpoints, and printfs in source, is that large, though. It's easier to write complex conditionals or log the state of a complex predicate in the source language than in whatever the debugger gives you - even if it gives you the native language, you typically have to write it all on a single line. And you need to dive deep into the source to understand where to put those breakpoints - or printfs. An underused debugging tool is an instrumenting profiler. The captured call graph is a useful clue for dynamic & indirect control flow in particular, without needing to decipher it from stepping or infer it from chasing source references and indirections. Things like generic message dispatchers and event callbacks are horrible to try and step through and aren't much better when eyeballing the source.
- saagarjha 6y ago
  FWIW, I rarely put debugging logs in my code-almost always in cases where I can't stick a breakpoint on something because I can't get a debugger on it. 99% of your debugging printfs can be breakpoint commands. They're actually better because they are separate from your source code, so you aren't going to accidentally commit them or anything, they can change dynamically without recompiling or even re-running, and they have access to a lot more information than your compiler may let you print out.
  - barrkel 6y ago
    It's generally hard to add breakpoints in production. OTOH most logging systems aren't set up for dynamic contextual reconfiguration, a place could have a competitive advantage over debuggers with a bit of effort. IME I find it easier to deal with modifications to code than configuration in IDEs, precisely because I can identify diffs and if desired commit the modifications to source control on my own branch. I frequently debug things like third-party libraries (e.g. Ruby gems by adding my rvm gemset) to a git repo to track my modifications. It's generally harder to export and import breakpoints from an IDE. They are usually driven by line numbers, which aren't particularly stable over code changes.

barrkel 6y ago

Funny thing about debuggers is that they seem to encourage stepping - step in, step out, step over, single step, step to return. Stepping is an enormous waste of time with a debugger. Breakpoints are where it's at. Level up your breakpoints: logging breakpoints, conditional breakpoints, memory breakpoints (super handy when combined with deterministic memory allocation), syscall / library breakpoints - and soon you're going somewhere useful. Debugging is about formulating theories and proving them wrong, or right. Stepping doesn't scale; breakpoints can scale, if you know where to put them. I'm not sure that the gap between a debugger with breakpoints, and printfs in source, is that large, though. It's easier to write complex conditionals or log the state of a complex predicate in the source language than in whatever the debugger gives you - even if it gives you the native language, you typically have to write it all on a single line. And you need to dive deep into the source to understand where to put those breakpoints - or printfs. An underused debugging tool is an instrumenting profiler. The captured call graph is a useful clue for dynamic & indirect control flow in particular, without needing to decipher it from stepping or infer it from chasing source references and indirections. Things like generic message dispatchers and event callbacks are horrible to try and step through and aren't much better when eyeballing the source.

saagarjha 6y ago
FWIW, I rarely put debugging logs in my code-almost always in cases where I can't stick a breakpoint on something because I can't get a debugger on it. 99% of your debugging printfs can be breakpoint commands. They're actually better because they are separate from your source code, so you aren't going to accidentally commit them or anything, they can change dynamically without recompiling or even re-running, and they have access to a lot more information than your compiler may let you print out.
- barrkel 6y ago
  It's generally hard to add breakpoints in production. OTOH most logging systems aren't set up for dynamic contextual reconfiguration, a place could have a competitive advantage over debuggers with a bit of effort. IME I find it easier to deal with modifications to code than configuration in IDEs, precisely because I can identify diffs and if desired commit the modifications to source control on my own branch. I frequently debug things like third-party libraries (e.g. Ruby gems by adding my rvm gemset) to a git repo to track my modifications. It's generally harder to export and import breakpoints from an IDE. They are usually driven by line numbers, which aren't particularly stable over code changes.