What a good debugger can do
I use GDB almost daily, and used Visual Studio pretty deeply for many years (and still a little bit, nowadays), but I must say I am still a &quot;printf debugging&quot; aficionado (or better: real logging).<p>I like many of the features that debuggers can provide, and I think this is a good article to set aspirational goals for what is possible. But my lived experience has generally been that it&#x27;s a buggy, fuzzy, moving target in terms of overall user experience. GDB, bless its heart, is still somewhat a pile-of-bugs itself. I frequently have it crash, or otherwise get into a &quot;so confused it needs to be restarted&quot; state. Visual Studio is much more stable, though less powerful, too — less scriptable, at least.<p>Perhaps some day, debugger tech^H^H^H^H UX will advance to the point where it really delivers on its promises consistently and solidly. But after 20+ years in software, I am not holding my breath (: There are some situations where a debugger is <i>just</i> the thing you want (eg: hardware breakpoints can be a life-saver), but I find that&#x27;s more the exception than the rule, at least in the corners of the software world I&#x27;ve worked in.<p>Compare the above with logging: It is simple and trustworthy. As you get good at designing a solid logging system, and interpreting the results, your life just gets better and better. If you get good at using a debugger, you can still be hit with gnarly weird behaviors, debugger apoplexy, optimized-out-code wackiness, etc. that are hard to control or predict.<p>Anyway, &quot;debugger vs. logging&quot; are often presented as some sort of either&#x2F;or choice, and in some sense it is (you only have X time to spend; where would you like to spend it?), but in many senses it is not; both have their strengths. I just find that the cost&#x2F;benefit for me has generally favored logging and testing, over the years.