Ah, I'm quite old fashioned when it comes to debugging, so I'll attach a debugger and maybe even read through the generated assembly if need be. I've also been trying to make more use of static asserts where possible. If I can ensure both me and the compiler have the same understanding of the code then there's hopefully less space for errors at runtime. But of course this is never going to eliminate the need for debugging, even if (and this is a big IF) the compiler knows my exact intent (i.e. my reasoning might be wrong somewhere, perhaps very subtly so). And static asserts are still quite hacky.
All that said, I totally agree that there are times when faster compiles are really useful.
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.
All that said, I totally agree that there are times when faster compiles are really useful.