But really, what do you use in their place? Do you work in an environment that is "debugger by default" (as opposed to a separate step where you need to "debug" instead of "run")?
"println debugging" is a tried and true strategy. Debuggers' firehose of information can start to get really hairy when you have multiple threads of execution, for example. "println debugging" (if you have the right tools) can get you 98% of the way there and show you exactly only the relevant information.
A lot of debuggers have a feature where you can stop the execution of threads you don't want to bother with, which I find to actually be more useful than println debugging.
It's not a satisfying answer really, but I use a bunch of log statements. It's definitely not as good as a debugger, but 9 times out of 10, it's sufficient.
This is one of the main things which has driven the development of julia's logging system; it seems that some people just don't like debuggers very much (I'm one of them) and find staring at logs and attempting to run the code in their head to be a productive alternative.
I think it's the difference between inspecting local vs global program behavior. A debugger gives a very local view of the program but the most difficult bugs are ones where the local behavior is (or seems) correct but the global behavior is wrong. In that case it can be much more useful to run the program to completion with plenty of logging and then to carefully inspect the record of how the state changed.
Yeah, and when I did node.js programming, the one time I ever got node-inspector working, I even would inject code in while paused on a breakpoint, which is undeniably useful.
Comments
Maybe you just don't write bugs ;)
But really, what do you use in their place? Do you work in an environment that is "debugger by default" (as opposed to a separate step where you need to "debug" instead of "run")?
"println debugging" is a tried and true strategy. Debuggers' firehose of information can start to get really hairy when you have multiple threads of execution, for example. "println debugging" (if you have the right tools) can get you 98% of the way there and show you exactly only the relevant information.
A lot of debuggers have a feature where you can stop the execution of threads you don't want to bother with, which I find to actually be more useful than println debugging.
It's not a satisfying answer really, but I use a bunch of log statements. It's definitely not as good as a debugger, but 9 times out of 10, it's sufficient.
This is one of the main things which has driven the development of julia's logging system; it seems that some people just don't like debuggers very much (I'm one of them) and find staring at logs and attempting to run the code in their head to be a productive alternative.
I think it's the difference between inspecting local vs global program behavior. A debugger gives a very local view of the program but the most difficult bugs are ones where the local behavior is (or seems) correct but the global behavior is wrong. In that case it can be much more useful to run the program to completion with plenty of logging and then to carefully inspect the record of how the state changed.
Have you tried using a debugger as a "dynamic print statement"?
Yeah, and when I did node.js programming, the one time I ever got node-inspector working, I even would inject code in while paused on a breakpoint, which is undeniably useful.