[fruzz]

Honestly, I don't get this debate.

If you were to take the pain points of debug by print, and address them, you'd come up with a debugger. Being able to put those "print" statements anywhere without recompiling, being able to go step-by-step in the code, etc. And sure, that's not always available.

Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to cause a race condition not to trigger, as can waiting on a breakpoint, etc. If you compile with debug symbols, that can cause some bugs not to surface, as they are only visible when you compile with -O3 or whatnot (eg. a bug involving reading unallocated memory).

Both are just tools. Sometimes one is better in a given situation. Sometimes the other is. I just don't get how this is like an emacs vs vim thing.

[akkartik]

> Both end up having impacts on the thing they observe. A print() call can cause microscopic delays that are enough to cause a race condition not to trigger, as can waiting on a breakpoint, etc.

I seldom encounter a program that is sensitive to a print() but robust to a debugger. Prints perturb programs _less_ than debuggers do.

> If you were to take the pain points of debug by print, and address them, you'd come up with a debugger.

Quoting myself from OP: The key skill it teaches is reasoning about a program by modifying it.. When might better debugging tools be counter-productive? If they cause you to forget that there is a debug cycle, and to stay too long observing when a new modification would get you to the answer faster.. Tools will always will have limits.. Prints prepare one for times when you have to leave your tools behind and enter the wilderness.

[mtVessel]

Am I understanding this correctly? Are you saying it's better to change things rather than understanding the existing code?

[sgtnoodle]

For embedded work, I've found great value in being able to observe and manipulate running systems without interrupting code execution. A non-blocking console buffer is very handy, but even more so is instrumentation for periodically sampling arbitrary variables cooperatively / in synch with program execution.

When you're making a 50KW motor spin under PID control, a debugger breakpoint can cause a lot of real damage.

[alphanumeric0]

I had a coworker once who was proud that he didn't know how to use a debugger. It was something about being able to statically analyze a program without dropping into a debugger that conveyed his superior skill. He only used print statements.

For me personally, I use both print statements and the debugger extensively. When I'm wrangling a hard to understand bug, I'll litter my code with print statements and then once I find a problem area I'll set a breakpoint. When I have more information, I'll even set a conditional breakpoint - I can't imagine wading through a lot of print statements after a few iterations when you know exactly which conditions will trigger your bug.

[superjan]

The tweet is not advocating print debugging per se, but about understanding the code by modifying it. This is how I approach any foreign/old code all the time, I can recommend it. If you have a theory about how it works, edit it, and see if your edit works expected. It may or may not, either way you learn something. I love debuggers, but editing the code can also help you trigger a breakpoint just before that special case hits. Much faster than conditional breakpoints.

[wtetzner]

Stepping through can be a pain sometimes, because to find certain bugs it's easier to look through a log throughout a longer run of the program, and see how the state changes.

Of course, a debugger that could generate a log like that instead of pausing execution would give you that benefit too.

[pjc50]

Yes, this seems like an odd missing feature that would give me the best of both worlds: a "watchpoint", but that outputs to a log. It may be possible in VS debug or gdb but it's not really .. surfaced?

[dezgeg]

In gdb you can put commands to be executed on a breakpoint; you can put necessary prints + continue statement there.

[searedsteak]

This is possible in all JetBrains IDEs, just right-click the breakpoint and configure it that way.