Ask HN: Why is output still popular in debugging? | Hacker News Reader

Ask HN: Why is output still popular in debugging?

I noticed that output debugging message is still the go-to method for many programmers even though they are aware of the presence of more advanced debugging tools such as break-point based debugger, which are often integrated in the IDE. I can only assume that stubbornness played a role here where printing message is a habit formed from early stage of many programmer. However is there other reasons for one to choose such methods than alternatives?

View on HN

> I noticed that output debugging message is still the go-to method for many programmers even though they are aware of the presence of more advanced debugging tools such as break-point based debugger, which are often integrated in the IDE.

The interim output debug message is the one method that is always available in whatever environment one happens to be programming in. When there is no debugger available, one could not use "the debugger" even if one wanted to do so.

Also, your statement presupposes that one is using an IDE. Some of us programmers out here despise all IDE's and never, ever, program with an IDE, ever. When there is no IDE, there is no "debugger ... integrated in the IDE".

Show me in the Drupal CMS how to debug a sites url, for a function body I believe to be in a stack trace of the urls processing.

I don't see IDEs as much help here because Drupal is so dynamic there's no easy way to jump through all the function/method calls that are useless calls to step through -- it's just easier to narrow down the debugging surface with well placed output messages.

Please someone point me at way to have the "setup" point me to the errors, and not me telling her debugger where I think the error is with a breakpoint...

If a condition infrequently happens, a logged debug statement that compiles with the code (or at least travels with the source code) can be preferable to keeping a breakpoint around in the IDE. I personally don't feel comfortable relying on the IDE to maintain an important breakpoint for an infrequent condition. (Having flashbacks of Visual Studio 2008 dropping or moving old breakpoints).

Different benefits come from each approach. Printing stuff out means you get a record of what happened during program execution, which you can compare to what you expect to have happened. With breakpoints, you have to keep track in your head, not only of where you are, but of where you expect to be. They can be useful too, but I probably use print statements about ten times as often.

> With breakpoints, you have to keep track in your head, not only of where you are, but of where you expect to be. They can be useful too, but I probably use print statements about ten times as often.

Thanks for putting this so clearly. That is the headache with breakpoints in complicated systems with lots of layers of indirection.

Reply on news.ycombinator.com