
Ask HN: Why is output still popular in debugging? - tonysickpony
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?
======
pwg
> 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".

------
tenken
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...

------
cVwEq
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).

------
sevensor
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.

~~~
tenken
> 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.

