I don't understand - how is using a debugger a waste of time?
I don't often use a debugger, but they have proven to be useful in a lot of cases.
I don't often use a debugger, but they have proven to be useful in a lot of cases.
I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).
And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.
The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does.
The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.
> by adding [...] comments, [...] etc
If you need a debugger, those are not there or not good enough, and you can only meaningfully add them after you understand what's happening.
(EDIT: there is also a wide variety in what people count as a "debugger" further muddying the debate)
To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project.
A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing.
Not even touching the places where a debugger solves a problem you simply can't touch with instrumentation after the fact (crash dumps immediately come to mind...).
And neither of them are (in any sense) a replacement for writing a test after you solve the problem, or adding comments so the next developer has context on the why of that piece of code.
I've had a fair share of using debuggers in my life, and I ended with my anti-debugging stance as a matter of fatigue, and a sense of time lost. I know what debuggers are capable of, especially regarding data visualization. But for your example of the variable watch, what are you going to watch, precisely? That the value of a variable is always positive? That it increases one by one? All these things are better served by assertions. What kind of information can be inferred by just looking at the evolution of values of a variable that is not easily formalized as an assert or a simple in-code test?
Basically - the debugger is not a tool I use if the issue is clear and reproducible.
Those are also issues where it can be hard to write a correct test up front. Typically - tests are passing already, but we're seeing intermittant problems somewhere. Once we understand the interaction and the root of the problem, it's much easier to put a test in place.