5 ms·

I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have s

I’m sorry but this is just ignorance, learning to use the debugger for the platform at hand is a basic skill every developer should master. So many times have seen developers use the debugger to troubleshoot and fixed issues and been perceived as a “ninja” (despise that term but that was the effect) because they knew how to use the debugger. I mean yeah keep printing lines, and keep being out performed by your debugger using peers. That’s the choice. Yes I am dieing on this hill.

axaxs 6y ago
OK. And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. Debuggers aren't bad. But neither is printing. Knowing when to reach for them is probably a bit more key.
- pjmlp 6y ago
  They weren't ninjas, otherwise they would have used breakpoint actions for doing those print statements without modifying the source code.
  - majjgepolja 6y ago
    What's breakpoint action? Is it like inserting printf before breakpoint?
    - edoceo 6y ago
      maybe this is sometimes called assert()? or in some debuggers you set a watch on a var and the BP triggers only on the watch-condition so the BP don't trigger each loop, only when x=7
    - formerly_proven 6y ago
      Breaking is just the default behavior when a breakpoint is hit, you can generally attach whatever behavior / conditions you want using the debugger's scripting language.
      - nomel 6y ago
        Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.
        pjmlp 6y ago
        I once saw an interview with Visual Studio members that one reason why they started doing talks about how to use the debugger was the continuous set of requests for features that Visual Studio does almost since it exists. Same applies to other debuggers. It is not only the debuggers, but also OS and language runtime tracing facilities like DTrace, eBPF, ETW, JFR, .... Many devs aren't 10x because of QI, rather because they learn and make use of the tools available to increase knowledge about the platform.
        frou_dh 6y ago
        Reminds me of this diagram http://i.imgur.com/ZOuf9hg.png http://i.imgur.com/ZOuf9hg.png (which I don't necessarily agree with)
        CJefferson 6y ago
        I agree, but my feeling is, if one person is bad at using debuggers it is their fault. If (as it seems to me) most developers are bad at using debuggers, then it's probably to debugger's (and associated tooling's) fault.
        pjmlp 6y ago
        For me it is the teacher's fault, given that a large majority never teaches anything related to debuggers. So we get generations that use vim and Emacs like notepad, create Makefiles by copy-paste and barely know gdb beyond set breakpoint, run, step and continue. Using C as example, but feel free to extrapolate to another language. And no I am not exaggerating, this was the kind of students I would get into my lab when I spent a year as TA in 1999/2000, and naturally would have to get them up to speed into good programming practices.
    - pjmlp 6y ago
      It maps breakpoints to debugger actions that are triggered instead of actually stopping execution, like formatted output of whatever variables are in scope.
- mmazing 6y ago
  Tools in a toolbox. The worst developers I've ever known always have their "this is the best way to do everything" hill they die on.
- dragonwriter 6y ago
  > And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. The problem is that the two print statements will only catch the bug if they are the right two, based on a correct hypothesis of what the bug is. Which, with a debugger, won’t require stepping, but setting two breakpoints, doing a run-to-breakpoint, and inspecting values. Stepping is required when you are exploring behavior because you don’t have an easily testable hypothesis about the source of the bug.
  - cratermoon 6y ago
    But with print statements if the first place I put them doesn't work, I can start doing bisects and quickly find the right place to print. As you note, debugger breakpoints aren't magically better than print statements when I'm investigating a hypothesis – I'm no more likely to put them the right place than I would have put print statements. And then there's a class of problems that neither debugger nor print statements will help: many years ago a very junior co-worker was wondering why his C code was giving the wrong answer for some math. It took me pointing out that one of the numeric types he was using in his code was different from the rest (I think it was #defined elsewhere, in some library, as an integer type). When the compiler did the math it had to do some type coercing.
    - dragonwriter 6y ago
      > And then there's a class of problems that neither debugger nor print statements will help: many years ago a very junior co-worker was wondering why his C code was giving the wrong answer for some math. It took me pointing out that one of the numeric types he was using in his code was different from the rest A debugger and watches on the values of concern absolutely will help with that (so will properly placed print statements), so its a really bad example. (Of course, strong typing helps even more with that particular case.)
      - cratermoon 6y ago
        No, my co-worker was so junior he didn't understand why that was happening. It took me a moment to glance at the types in the source and point out the problem, no debugger needed.
zeta0134 6y ago
I've used print debugging extensively doing embedded development, when I could reasonably hook up a serial port to capture the output, or put a crude console on a tiny screen. These systems can't always be debugged in the traditional sense, and if you're troubleshooting some bug that happens on hardware but not in your simulator, then you use the tools you have available.
- deleted 6y ago
  [deleted]
CJefferson 6y ago
I do use debuggers when I have a hard core problem, I've found some horrible memory corruptions using RR and gdb for reverse debugging. However, sometimes someone throws a horrible gradle java project at you and asks for help, and figuring out how to debug is a pain. I'd throw your comment back -- maybe all languages should be "debug first", make it as easy to get code into a debugger as it is to just build and run it.
d0mine 6y ago
You are missing out on the important point: printing forces you to formulate a hypothesis: what you expect and to compare with what you actually get. Debugging encourages less modeling and more trying random stuff until something sticks. It is an exaggeration. In practice, it is useful to apply both. Novices can get some insight using debugging, more experienced with code base people should exercise their understanding of the code and use well picked prints.
- SAI_Peregrinus 6y ago
  You can also do print debugging with a debugger. Just have a breakpoint that doesn't halt, but instead simply prints the values of interest to the debugger console. This is particularly nice for things like debugging interrupt handlers where the time taken to print output normally is too much to accept.
  - toxik 6y ago
    Watched variables they were called once upon a time. Also, I think what you suggest to do here is way harder to learn than printing.
    - saagarjha 6y ago
      Perhaps, but that lends credence to the theory that people using print debugging may just not have learned how to effectively use a debugger yet.
xondono 6y ago
I’m also willing to bet you live way up the stack. Try debugging something in the embedded world, and you’ll see why a lot of bare metal programmers use printfs. Turns out timing is critical most of the time, so using a debugger hides a LOT of bugs from your eyes. Debuggers are very useful, but so are prints, there just different tools, they have different purposes.
deleted 6y ago
[deleted]

axaxs 6y ago

OK. And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. Debuggers aren't bad. But neither is printing. Knowing when to reach for them is probably a bit more key.

pjmlp 6y ago
They weren't ninjas, otherwise they would have used breakpoint actions for doing those print statements without modifying the source code.
- majjgepolja 6y ago
  What's breakpoint action? Is it like inserting printf before breakpoint?
  - edoceo 6y ago
    maybe this is sometimes called assert()? or in some debuggers you set a watch on a var and the BP triggers only on the watch-condition so the BP don't trigger each loop, only when x=7
  - formerly_proven 6y ago
    Breaking is just the default behavior when a breakpoint is hit, you can generally attach whatever behavior / conditions you want using the debugger's scripting language.
    - nomel 6y ago
      Reading through the majority of this comment section, I get the impression that those who like print statements find value because they aren’t proficient with modern debuggers, rather than they find print statement valuable even though they’re proficient with debuggers.
      - pjmlp 6y ago
        I once saw an interview with Visual Studio members that one reason why they started doing talks about how to use the debugger was the continuous set of requests for features that Visual Studio does almost since it exists. Same applies to other debuggers. It is not only the debuggers, but also OS and language runtime tracing facilities like DTrace, eBPF, ETW, JFR, .... Many devs aren't 10x because of QI, rather because they learn and make use of the tools available to increase knowledge about the platform.
      - frou_dh 6y ago
        Reminds me of this diagram http://i.imgur.com/ZOuf9hg.png http://i.imgur.com/ZOuf9hg.png (which I don't necessarily agree with)
      - CJefferson 6y ago
        I agree, but my feeling is, if one person is bad at using debuggers it is their fault. If (as it seems to me) most developers are bad at using debuggers, then it's probably to debugger's (and associated tooling's) fault.
        pjmlp 6y ago
        For me it is the teacher's fault, given that a large majority never teaches anything related to debuggers. So we get generations that use vim and Emacs like notepad, create Makefiles by copy-paste and barely know gdb beyond set breakpoint, run, step and continue. Using C as example, but feel free to extrapolate to another language. And no I am not exaggerating, this was the kind of students I would get into my lab when I spent a year as TA in 1999/2000, and naturally would have to get them up to speed into good programming practices.
  - pjmlp 6y ago
    It maps breakpoints to debugger actions that are triggered instead of actually stopping execution, like formatted output of whatever variables are in scope.
mmazing 6y ago
Tools in a toolbox. The worst developers I've ever known always have their "this is the best way to do everything" hill they die on.
dragonwriter 6y ago
> And I've also cringed watching ninjas step through code slowly, reading everything, spending 20 mins catching something 2 print statements would have achieved. The problem is that the two print statements will only catch the bug if they are the right two, based on a correct hypothesis of what the bug is. Which, with a debugger, won’t require stepping, but setting two breakpoints, doing a run-to-breakpoint, and inspecting values. Stepping is required when you are exploring behavior because you don’t have an easily testable hypothesis about the source of the bug.
- cratermoon 6y ago
  But with print statements if the first place I put them doesn't work, I can start doing bisects and quickly find the right place to print. As you note, debugger breakpoints aren't magically better than print statements when I'm investigating a hypothesis – I'm no more likely to put them the right place than I would have put print statements. And then there's a class of problems that neither debugger nor print statements will help: many years ago a very junior co-worker was wondering why his C code was giving the wrong answer for some math. It took me pointing out that one of the numeric types he was using in his code was different from the rest (I think it was #defined elsewhere, in some library, as an integer type). When the compiler did the math it had to do some type coercing.
  - dragonwriter 6y ago
    > And then there's a class of problems that neither debugger nor print statements will help: many years ago a very junior co-worker was wondering why his C code was giving the wrong answer for some math. It took me pointing out that one of the numeric types he was using in his code was different from the rest A debugger and watches on the values of concern absolutely will help with that (so will properly placed print statements), so its a really bad example. (Of course, strong typing helps even more with that particular case.)
    - cratermoon 6y ago
      No, my co-worker was so junior he didn't understand why that was happening. It took me a moment to glance at the types in the source and point out the problem, no debugger needed.

zeta0134 6y ago

I've used print debugging extensively doing embedded development, when I could reasonably hook up a serial port to capture the output, or put a crude console on a tiny screen. These systems can't always be debugged in the traditional sense, and if you're troubleshooting some bug that happens on hardware but not in your simulator, then you use the tools you have available.

deleted 6y ago
[deleted]

CJefferson 6y ago

I do use debuggers when I have a hard core problem, I've found some horrible memory corruptions using RR and gdb for reverse debugging. However, sometimes someone throws a horrible gradle java project at you and asks for help, and figuring out how to debug is a pain. I'd throw your comment back -- maybe all languages should be "debug first", make it as easy to get code into a debugger as it is to just build and run it.

d0mine 6y ago

You are missing out on the important point: printing forces you to formulate a hypothesis: what you expect and to compare with what you actually get. Debugging encourages less modeling and more trying random stuff until something sticks. It is an exaggeration. In practice, it is useful to apply both. Novices can get some insight using debugging, more experienced with code base people should exercise their understanding of the code and use well picked prints.

SAI_Peregrinus 6y ago
You can also do print debugging with a debugger. Just have a breakpoint that doesn't halt, but instead simply prints the values of interest to the debugger console. This is particularly nice for things like debugging interrupt handlers where the time taken to print output normally is too much to accept.
- toxik 6y ago
  Watched variables they were called once upon a time. Also, I think what you suggest to do here is way harder to learn than printing.
  - saagarjha 6y ago
    Perhaps, but that lends credence to the theory that people using print debugging may just not have learned how to effectively use a debugger yet.

xondono 6y ago

I’m also willing to bet you live way up the stack. Try debugging something in the embedded world, and you’ll see why a lot of bare metal programmers use printfs. Turns out timing is critical most of the time, so using a debugger hides a LOT of bugs from your eyes. Debuggers are very useful, but so are prints, there just different tools, they have different purposes.

deleted 6y ago

[deleted]