You’ve just given the reason I often use to explain why printf debugging is something I’m not a fan of. For native development, printf debugging takes a backseat to proper instrumentation and debuggers just for sheer productivity reasons IMO. The main thing it gives is a serializable log for debugging multithreaded bugs. However, for just viewing state during a run, I think people should just learn to use their debugger (which can inject prints and watches on the fly, no need to recompile).
I agree with you, the main reason I stick to printf debugging is because I can't be bothered to change my habits, it's not a very sensible choice.
That being said, if I had to defend myself, I'd point out that printf debugging has a few advantages:
- It's often more lightweight and less intrusive than debuggers, which makes it less likely to encounter an "heisengbug" that disappears when you attempt to debug it. This is especially true for timing-sensitive bugs (which occur in multithreaded code as you point out, but not only).
- Debuggers are often environment-specific, if you change language, environment or even simply editor you might have to re-learn how to use your debugger. Printf will always be here for you.
- I do a lot of work in embedded environments, including low level and bare metal stuff (bootloaders, drivers etc...). While these days there's generally some debugger support available for these targets it's often more limited or much more intrusive. If I put a breakpoint in an interrupt handler I basically freeze the entire kernel when it triggers which can sometimes do more harm than good if I'm trying to figure out what's going on. And again, in these environments the debugging solutions are often proprietary and sometimes quite expensive.
Yea, I do graphics programming mainly and I suppose console development resembles embedded to a certain degree. I guess part of my preference is that I really don't have a choice. The codebase I'm currently in can take minutes to dozens of minutes to compile. This is compounded by the fact that just loading the engine takes a long time, and loading levels/assets to get to the point where I can reproduce the bug again takes more time. I have to deal with heisenbugs a lot, so necessity has more or less forced me to learn the toolchain (or never get anything done).
It is true though that if there are bugs in the toolchain, it affects me a lot more. For my personal projects, I actually avoid windows and "fancy" GUI based tools. I also painstakingly write all my code so they either compile fast or can hot-reload.
