4 ms·

>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?

>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 4y ago
> Who? Who does say that? Freshman students who barely started coding? Example from this thread: https://news.ycombinator.com/item?id=35098434 https://news.ycombinator.com/item?id=35098434
- justeleblanc 4y ago
  Do we know if that person is a freshman student who barely started coding?
  - bornfreddy 4y ago
    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 4y ago
      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 4y ago
Linus Torvalds famously dislike them: https://lwn.net/2000/0914/a/lt-debugger.php3 https://lwn.net/2000/0914/a/lt-debugger.php3
- justeleblanc 4y ago
  At least he did 23 years ago. Have debuggers evolved in the past 23 years?
  - aflag 4y ago
    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.
    - thewebcount 4y ago
      > 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.)
q845712 4y ago
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 4y ago
  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 https://www.informit.com/articles/article.aspx?p=1941206>
ithkuil 4y ago
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.
hinkley 4y ago
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.

maleldil 4y ago

> Who? Who does say that? Freshman students who barely started coding? Example from this thread: https://news.ycombinator.com/item?id=35098434 https://news.ycombinator.com/item?id=35098434

justeleblanc 4y ago
Do we know if that person is a freshman student who barely started coding?
- bornfreddy 4y ago
  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 4y ago
    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 4y ago

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

justeleblanc 4y ago
At least he did 23 years ago. Have debuggers evolved in the past 23 years?
- aflag 4y ago
  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.
  - thewebcount 4y ago
    > 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.)

q845712 4y ago

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 4y ago
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 https://www.informit.com/articles/article.aspx?p=1941206>

ithkuil 4y ago

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.

hinkley 4y ago

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.