5 ms·

"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it,

"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.

planteen 10y ago
With prints and a backtrace function, you can make up for a most debugger usage. But for tracking down heap corruption, a debugger with memory breakpoints is the bees knees.
RX14 10y ago
There's no shame in it but that doesn't mean that it's the best or most efficient way of doing things. I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.
- MichaelBurge 10y ago
  One problem with this, is that your code often ends up in a state where only step-through debugging works anymore. It might become too complex to reason about just looking at the code, from the types alone, or by printing data. Same problem happens with other methods too: If you develop solely with unit and integration tests, it might actually be quite difficult to get a step-through debugger set up to debug your application. I worked at a company where I was the only one who used a step-through debugger, and some uses of compile-time metaprogramming would frequently break the debugger. And if you use multiple techniques as appropriate(unit tests, printf or equivalent, step-through debugging), it's generally easy to use any of them as appropriate.
- greglindahl 10y ago
  Like every other tool in programming, different people have different preferences and experiences. Symbolic debuggers have always ended up being a waste of my time, but I don't try to extrapolate from there to everyone else's preferences.
- reddit_clone 10y ago
  I don't trust debuggers with multi-threaded programs. Organized (multi verbose level) tracing built right into the application can go a long way before you actually need a debugger.
cjhanks 10y ago
Yeah. Sometimes I find it easier to write a program parsing log files with the line number and PID to step through. Sometimes I think the people who have success with debuggers often must be working on a different class of problems than I am familiar with. Numerical problems can usually be fixed with a series of targeted asserts and logs.

"My primary debugging tool is Console.Writeline(). To be honest, I think that's true of a lot of programmers." --Anders Hejlsberg If Anders Hejlsberg does it, there's no shame in it.

planteen 10y ago

With prints and a backtrace function, you can make up for a most debugger usage. But for tracking down heap corruption, a debugger with memory breakpoints is the bees knees.

RX14 10y ago

There's no shame in it but that doesn't mean that it's the best or most efficient way of doing things. I've found that stepping through code in a debugger at a human pace, and getting to really understand what's happening when a bug occurs is invaluable.

MichaelBurge 10y ago
One problem with this, is that your code often ends up in a state where only step-through debugging works anymore. It might become too complex to reason about just looking at the code, from the types alone, or by printing data. Same problem happens with other methods too: If you develop solely with unit and integration tests, it might actually be quite difficult to get a step-through debugger set up to debug your application. I worked at a company where I was the only one who used a step-through debugger, and some uses of compile-time metaprogramming would frequently break the debugger. And if you use multiple techniques as appropriate(unit tests, printf or equivalent, step-through debugging), it's generally easy to use any of them as appropriate.
greglindahl 10y ago
Like every other tool in programming, different people have different preferences and experiences. Symbolic debuggers have always ended up being a waste of my time, but I don't try to extrapolate from there to everyone else's preferences.
reddit_clone 10y ago
I don't trust debuggers with multi-threaded programs. Organized (multi verbose level) tracing built right into the application can go a long way before you actually need a debugger.

cjhanks 10y ago

Yeah. Sometimes I find it easier to write a program parsing log files with the line number and PID to step through. Sometimes I think the people who have success with debuggers often must be working on a different class of problems than I am familiar with. Numerical problems can usually be fixed with a series of targeted asserts and logs.