Interesting. To each his own, of course - but in this one particular video, the print-debugging he does, might have been quicker and easier in a debugger (or perhaps with a core dump?). Then again, maybe not in c++.

I admit, I work mostly with ruby these days, which of course has a quite decent repl and debug experience (still whish it had full smalltalk style crash(missing method) > debugger > fix/add method > resume). Apparently someone did try that with python/rpython in the "topaz" ruby vm, but it seems abandoned. Maybe we'll get it for more languages via graal vm at some point?).

I'm used to fix and understand issues in big C++ codebases, and while eventually use a debugger, i feel that printing while passing is much better because you can see the bigger picture.

Is like putting a bell in each step so when the running bunny passes over it rings.

Later you see every place the bunny passes over and what it did, i feel its much faster to grasp and understand whats happening.

Debugging feels very slow, and i mostly use it to analyze core dumps. Also in multi-threaded/multi-process code it can change the result/output as other parts (like processes) might still run detached from the debugged thread.

Anyway, i don't like forced rules, you should use whatever works the best for you, because in the end we all have a intelligence to analyze things for our particular scenario much better than someone with a generalized point of view can.

We should always be open to learn and to see other perspectives but once we are settled we should also learn to trust ourselves and bend the "rules" when there's a need.

Multiple threads can change behavior, especially if it is a thread safety problem you are debugging. Debugging takes time mostly to reproduce the bug. If you had rr I think it might be as fast as using good logs.

That's somewhat true, it changes to me when rr works and so you can basically do print where you want and going back if you forgot something.

There's a scene in Netflix's The Queen's Gambit where two skilled Chess players are driving to New York. During the monotonous drive, they decide to play Chess. But they do so entirely verbally, no board involved as they are skilled and are able to hold the boards state within their heads.

The best way to explain how I debug is through this metaphor. I don't need the debugger to know what's happening. I know exactly what's happening with my code. The only reason I use print statements is to know what's being returned to me through other people's black boxes. I don't want to be limited to one black box query per run, so I can add multiple statements exactly where I think the black box is being weird.

I use a debugger to step into libraries and other people’s code regularly. Irrespective of whether I can or cannot hold the logic in my end I don’t find it particularly useful.

I’m not sure why a useful utility is so polarising. It’s a helpful aid - like a chisel in a carpenter’s toolbox.