3 ms·

I've always found debugging primarily via logging statements strange, we have interactive debuggers which allow us to pause execution, analyze the current stack

by shruubi 11y ago

I've always found debugging primarily via logging statements strange, we have interactive debuggers which allow us to pause execution, analyze the current stack and monitor your variables to ensure correct values and people still feel that writing stuff to the console is the best way to debug? That being said, I'm not trying to take anything away from log-based debugging, there have been many times when log-based debugging has saved my bacon, but it feels strange that there is almost an attitude of interactive debuggers being "lesser" in these comments.

marssaxman 11y ago
It's just science: debugging is the art of generating and testing hypotheses about the behavior of a complex system, so what's important is that you can run an experiment, observe the results, and update your model accordingly. Logging may not be the best way to debug a problem but sometimes it is the only way to debug a problem - interactive debuggers may or may not be able to help, depending on the situation, but "write code that produces data, run the code, look at the data, learn what the code did" is a strategy which always gets the job done. When you have a choice between a primitive tool which will definitely work and a sophisticated tool which may or may not work, sometimes you just want to get on with it, and whatever time you have to spend thinking about your tools is time you can't spend thinking about the problem you're actually trying to solve. I once debugged a bootloader issue on an embedded device with no feedback but a single blinking LED. It took a while, but I kept trying different things, "logging" the program's output via patterns of blinks, and staring at that flashing light through test after test eventually told me what I needed to know. On the other end of the scale, during the minute or so I worked at Google, the "library" I worked on that various "applications" would "link against" was actually an armada of independent processes on separate machines in a giant datacenter firing reams of HTTP requests and responses at each other. Stopping one of them and interrogating it via debugger would have been about as informative as the conversation I'd have with an ant if I caught it in a jar and asked why its friends decided to have a party in my kitchen. Between those extremes, there undoubtedly exist many places where interactive debuggers would be useful; but having spent enough time unable to count on them, the effort it takes to use such tools grows increasingly difficult to justify.

by shruubi 11y ago

marssaxman 11y ago

It's just science: debugging is the art of generating and testing hypotheses about the behavior of a complex system, so what's important is that you can run an experiment, observe the results, and update your model accordingly. Logging may not be the best way to debug a problem but sometimes it is the only way to debug a problem - interactive debuggers may or may not be able to help, depending on the situation, but "write code that produces data, run the code, look at the data, learn what the code did" is a strategy which always gets the job done. When you have a choice between a primitive tool which will definitely work and a sophisticated tool which may or may not work, sometimes you just want to get on with it, and whatever time you have to spend thinking about your tools is time you can't spend thinking about the problem you're actually trying to solve. I once debugged a bootloader issue on an embedded device with no feedback but a single blinking LED. It took a while, but I kept trying different things, "logging" the program's output via patterns of blinks, and staring at that flashing light through test after test eventually told me what I needed to know. On the other end of the scale, during the minute or so I worked at Google, the "library" I worked on that various "applications" would "link against" was actually an armada of independent processes on separate machines in a giant datacenter firing reams of HTTP requests and responses at each other. Stopping one of them and interrogating it via debugger would have been about as informative as the conversation I'd have with an ant if I caught it in a jar and asked why its friends decided to have a party in my kitchen. Between those extremes, there undoubtedly exist many places where interactive debuggers would be useful; but having spent enough time unable to count on them, the effort it takes to use such tools grows increasingly difficult to justify.