[Jorengarenar]

>When people say “debuggers are useless and using logging and unit-tests is much better,”

Who? Who does say that? Freshman students who barely started coding?

>I suspect many of them think that debuggers can only put breakpoints on certain lines, step-step-step through the code, and check variable values.

That alone provides enough value to know debuggers are useful.

[maleldil]

> Who? Who does say that? Freshman students who barely started coding?

Example from this thread: https://news.ycombinator.com/item?id=35098434

[justeleblanc]

Do we know if that person is a freshman student who barely started coding?

[bornfreddy]

There are many other experienced devs (me included) who simply don't see debuggers worth the effort in most cases. There are exceptions and every competent dev should know how to use one, but to me it is like using crutches - I run faster and better without them. I did use debuggers at the beginning though, a lot too. Then I learned to think about problems and to simplify design of the code, making debuggers much less useful.

[maleldil]

I find it useful to run pdb when my program throws an exception. You can run your program with `python -m pdb -cc file.py args`, and it will leave you in a prompt when there's an exception or a breakpoint (eg the `breakpoint` statement). From there, you can evaluate expressions using local variables.

[aflag]

Linus Torvalds famously dislike them: https://lwn.net/2000/0914/a/lt-debugger.php3

[justeleblanc]

At least he did 23 years ago. Have debuggers evolved in the past 23 years?

[aflag]

They have a little. But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems.

That aspect of debuggers hasn't changed in 23 years, because that's the whole point of debuggers anyway.

Some projects are better off with a debugger and some developers are more productive with them. But also the other end of the spectrum exists: projects that are better off without and developers who are more productive without them. Not liking debuggers don't mean someone is stupid or inexperienced.

I'd even dare say that's more likely an experienced developer to not use debuggers as much as people earlier in their careers. Seasoned developers working for a long time in the same code base are more likely to have insight of what's going on without stepping through the process execution.

[yencabulator]

> But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems.

Said differently by other old beards in this classic of Ken Thompson & Rob Pike: https://www.informit.com/articles/article.aspx?p=1941206

> When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.

[roca]

That could work in the old Unix days, and for toy problems today. But if Firefox crashes you can't just build a mental model of 10M lines of code and intuit the problem.

[aflag]

Having a mental model doesn't require you to read all the code. But even if it did, most people work with much smaller code bases anyway.

[thewebcount]

> But his main point is that debuggers distract developers from seeing the problem as a whole rather than just understanding what's going on the vicinity of that problematic line. So, the debugger incentivises small, targeted fixes rather than bigger solutions for more systematic problems.

What a bizarre take. Just today I had to use a debugger to figure out where there was a deadlock in our program and why. No amount of printfs would have made that speedy. In the debugger I just stop the program once it's hung and look at all the threads to see which threads are holding which locks and which are waiting to obtain locks. From there I can now see it's a lock inversion because we weren't being careful about the order of taking our locks in a few places. That lead to doing a wider check to see if there were other similar cases, and whether we needed to rethink anything in particular.

The debugger generally gives me an overview of the whole program in a way that a bunch of printf statements can't. (Which isn't to say that printf doesn't have a place in debugging - it certainly does.)

[aflag]

There’s more than one way to skin a cat. People not using a debugger are not mindlessly adding prints, sort of a poor man’s debugger. Those people are figuring out the problem from a different perspective. In your case, one may trying to come up with a theory as to what could cause a deadlock and think of ways to cause it to always happen consistently. Before running anything, they would be trying to understand what could possibly go wrong. Then they test the theory. You can perhaps see that, if someone is always doing that, they can get quite good at it. They would also develop quite a good intuition on what to expect from the code base over time. Whereas, someone who just goes straight to a debugger may not develop such an intimate relationship with the code base.

It depends on individual’s strengths and weakness as well. Neither way is going to be better for everyone. Each person has to find out what works for them.

[bornfreddy]

Thank you for the link, well worth the read.

[ithkuil]

25 years in the industry. I used the debugger countless times because it was useful.

But I still default to use printf/log/tracing debugging style because it's often easier to get some signal under the conditions I care about and are hard to reproduce where it's hard to attach a debugger.

[q845712]

in my experience a large portion of go programmers seem to think this. I would guess (but haven't confirmed) that there's someplace where rob pike and/or russ cox are on the record telling folks that they don't really need debuggers because printf is great.

[cxr]

Rob Pike goes quite a bit further than that—don't even use printf or look at stack traces:

> A year or two after I'd joined the Labs, I was pair programming with Ken Thompson [...] Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.¶ I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.

<https://www.informit.com/articles/article.aspx?p=1941206>

[hinkley]

There are a lot of middle to late career developers who write code that is difficult to debug. It's a feedback loop. You write garbage code, the debugger is confusing, so you use the debugger less, so you get less feedback on your garbage code, until eventually other people can't debug your code either, or only invest the energy to do so when something has gone horribly wrong.

Or you write debugger-legible code, you use the debugger, and you get feedback when the code you wrote confuses the debugger, so you refactor it to be easier to diagnose the problem, then you commit those changes.