Hacker News Reader

Comment by alwaysbeconsing | Hacker News Reader

I find this take odd. To me, debugging with breakpoints is just a more powerful and flexible version of thinking about where to put printfs. You still have to think carefully about where to put the breakpoints, too.

If I sprinkle a couple of prints and my hypothesis about what state I need to see is wrong, then I have to do another build and run cycle to get more information. If I'm stopped at a breakpoint I can dynamically and interactively root around without having to go through the whole scenario again.

Maybe this is just a different mode of using the debugger than what's being argued against. I will say that stepping through is really only fruitful in my experience when there's an extremely narrow region of code that I've identified as causing the problem.

View on HN

Hah, yep. And further, sometimes a logging statement can cause a few ms of delay that causes whatever you're debugging to just magically start working again (yay, race conditions). A breakpoint has a better chance of catching it in the act than a logging statement does. At least in my experience.

Interesting. This probably varies by tech stack, but in my experience debugging concurrent/async stuff is where I will actually lean away from the debugger for fear of that kind of timing skew.

The case they are describing is when you know exactly where the error appears, but do not know how it appears. So you put in one breakpoint that will be hit exactly once when it rears its head instead of continuing over breakpoints which causes the timing skew you are talking about.

In any event, standard console logging is an abomination and there are much better encoded logging techniques that are exactly as usable and just as easy to add to your code, while not introducing material timing skew.

Yeah, but debuggers have a hard time capturing state history and displaying it in a useful way. Often times, the bug is a lot easier to understand if you see the historical values printed to the terminal, but is not at all obvious just by inspecting the current value of variables. This is especially true in any system with feedback, which is nearly any non-trivial system. Bugs can become so much more obvious if you see how state is changing through time, which print debugging is better at than debuggers and "plot debugging" is best at.

Right, but again, you can do exactly that with breakpoints (especially if they can print and then auto-continue), and you can change your output, adding or disabling them while still running.

That is because those debuggers use primitive technology from over 50 years ago. Use a time travel debugger in the last 20 years and you have perfect state history of all values over all time.

Print debugging only captures what you think to capture. Time travel debugging captures everything. And with a proper implementation the overhead is minor.

With prints, I'm usually not targeting one spot to see if it looks right, I'm putting them broadly over everything that gets hit to find where the data diverges from my expectations. Maybe I'll do another round to narrow it down some more, but it's only after finding the right place like that that I'd use the debugger, so I don't have to waste time stepping through everything.

100% agree, i don't even see any difference with print statements, what was all this pontificating about? it's literally just a different way to do the same thing as print statements - find out if the program reached that step and some values.

Reply on news.ycombinator.com