Most languages let you print the stack, so you can easily see the stack using print debugging.

Anecdotally, dynamic expressions are impossibly slow in the cases I’ve tried them.

As the author mentions, there are also a number of cases where debuggers don’t work. Personally, I’m going to reach for the tool that always works vs. sometimes works.

▲ ksenzee 5 days ago | parent | next [-]

> I’m going to reach for the tool that always works vs. sometimes works.

This is only logical if you're limited to one tool. Would you never buy a power tool because sometimes the power goes out and a hand tool is your only choice?

▲ nchmy 5 days ago | parent | prev [-]

but can you go back in the stack and inspect the variables and related functions there in print debugging?

▲ truetraveller 5 days ago | parent | next [-]

This is something that does not require a debugger perse. this is something that can be implemented by a "smart" log. beside the log entry there might be a button to see the trace + state at those points. could even allow log() to have an option for this.

▲ nananana9 5 days ago | parent [-]

But you have to

  1. stop the program
  2. edit it to add the new log
  3. rebuild the program
  4. run it
  5. get the program to the same state to trigger the log

3. can take quite a while on some projects, and 5. can take quite a while too for long-running programs.

And then you see the result of what you printed, figure out you need something else as well, and repeat. Instead you can just trigger a breakpoint and inspect the entire program's state.

▲

pavon 4 days ago | parent | next [-]

For 3, printf debugging is often faster for me because it only requires an incremental rebuild. Whereas with gdb, it is very likely that the release build doesn't show me what I want to see, so I need to do a full debug build from scratch which takes much longer, and sometimes no longer replicates the bug.

	▲	o11c 4 days ago \| parent [-]
		That hints that you might be doing one of three things wrong. Either: * You're using to doing things the Windows way, where debug and release are completely different profiles rather than orthogonal flags. Or, * You're compiling using Clang, which gives up and limits debuggability to simple backtraces when optimization is on. Or, * Your project is hopelessly bloated and linking with debuginfo is slow, but you haven't figured out external debuginfo. With GCC, `-g -O2` is a reasonable thing to use for all builds and provides a pretty good debugging experience with only minor competence required to find equivalences for any <optimized out>s.

▲

ranger_danger 4 days ago | parent | prev [-]

https://rr-project.org/

▲ MangoToupe 5 days ago | parent | prev [-]

...yes? You just print in the relevant stack frame.

There is an inherent tradeoff between interaction and reproducibility. I think the whole conversation of debugger vs print debugging is dumb. Just do whatever makes you the most productive. Often times it is immediately obvious which makes more sense.

	▲	nchmy 4 days ago \| parent [-]
		I agree, both are useful. But debuggers is vastly more useful for this particular case, most of the time. The parent comment that I replied to was trying to say otherwise