3 ms·

Do You Use a Debugger?

5 points by ingve 2y ago

deleted 2y ago
[deleted]
sevensor 2y ago
Very language dependent. Long build times mean you may need a debugger. Debugging prints make you think harder in advance and can actually force you to structure your code with greater clarity. The fact that you have to understand what they mean across two different contexts, writing and running, slows things down but also improves your mental picture of the codebase. Debugging prints don’t get enough credit.
marssaxman 2y ago
I used debuggers all the time when I used to work on interactive GUI applications. I am sure I could still remember how, if I had a need, but in the meantime I've spent years working on hardware drivers, embedded firmware, distributed systems, ML pipelines, and other such environments where debuggers would be unhelpful or impossible. Mostly I debug by looking at logs, and by thinking over their implications; you get used to it. Debugging is not really about the software, after all; it's a process of discovering the limits of your own understanding and identifying the flaws in your mental models. You make hypotheses and test them, and it doesn't matter so much what instruments you use to perform the tests, so long as you know how to think about the process systematically.
- PaulHoule 2y ago
  You can get all kinds of tools for debugging embedded systems, like https://onlinedocs.microchip.com/oxy/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B-en-US-4/GUID-2E228ACE-9E8D-4350-BB97-82CCC430629A.html https://onlinedocs.microchip.com/oxy/GUID-DDB0017E-84E3-4E77... of course if your problem is timing sensitive you have a problem. (A project to make a display controller for AVR-8 PoV displays got bogged down because of that)
  - beardyw 2y ago
    Yes there are tools, but it would be interesting to find out how much they are used. How often is timing not a problem?
  - marssaxman 2y ago
    I did use JTAG from time to time during that period of my career, but it was not as often useful as one might hope, usually as you say due to timing issues. I got really comfortable hooking up a serial port and streaming logs out at 9600 bps, or just clipping an LED or scope to a spare output and watching what it did. Then, sometimes it just didn't feel like it was worth the trouble of setting up the JTAG, when I knew I could turn it around in a minute with a simpler test.
    - PaulHoule 2y ago
      That was where I was heading with my display controller, except the 9600 bps wasn't good enough, the serial connection wasn't so reliable so I was trying to make a really simple protocol like HLDC [1] but life got in the way. If I ever get back to the project (putting an LED sign on the side of my car such that you might see some hearts and stars and stuff if you looked at it the right way) I might try testing the display controller in an emulator or put the strip on a pendulum or something so I can get a picture of it doing its thing. [1] https://en.wikipedia.org/wiki/High-Level_Data_Link_Control https://en.wikipedia.org/wiki/High-Level_Data_Link_Control
PaulHoule 2y ago
Plenty. The difference is I'm using commercial tools (PyCharm, WebStorm, and IntelliJ) that have visual debugging that works. Now gdb from the command line is great for what it is, but a lot of people who use open source toolchains find that "it just doesn't work" when it comes to debugging. Myself, I think tests and debugging go together like peanut butter and jelly. That is, you use tests to set up a situation you want to debug, then you run the debugger. When you're all done you have a test that proves the bug was fixed. It might be less of a problem in the C++ world but I really like being able to use the debugger to investigate a situation without touching the source code at all, since if you start hacking on the source code to add printfs and add other debugging hacks you often wind up checking in things accidentally that you shouldn't have, particularly when you're also making real changes to fix the bug. An arXiv paper [1] investigates those accidental commits and reveals that people do a lot of printf debugging of async callbacks since those can be hard to debug; they breakpoint just find in most environments but you never really know if they are going to run or not and I think a lot times they get called N times for harmless things before you get the one you want to breakpoint. (Maybe it's just me but I've never had good luck with conditional breakpoints) [1] https://arxiv.org/abs/2501.09892 https://arxiv.org/abs/2501.09892
- ai-christianson 2y ago
  > Myself, I think tests and debugging go together like peanut butter and jelly. That is, you use tests to set up a situation you want to debug The hardest things are the ones that come up in prod/after it is already deployed and there's no obvious error message or indication something is wrong. E.g. rn, I'm building a SWE agent (https://ra-aid.ai https://ra-aid.ai), and running it against SWE-bench lite. The processes will run for 5+ hours and then randomly hang. So for stuff like this, I rely heavily on: 1) Verbose logging 2) Tools that let you inspect/debug running processes, e.g. py-spy.
eternityforest 2y ago
Ability to use the debugger is one of my top priorities, I will often redesign an entire plan of it breaks the debugger (Either because it uses DSLs, or it's too strongly multi language, or it's not runnable locally on the desktop at all). Same for version control, linting, and formatting, I pretty much ignore technologies that don't integrate with all the modern dev tools most of us expect to have.

5 points by ingve 2y ago

deleted 2y ago

[deleted]

Very language dependent. Long build times mean you may need a debugger. Debugging prints make you think harder in advance and can actually force you to structure your code with greater clarity. The fact that you have to understand what they mean across two different contexts, writing and running, slows things down but also improves your mental picture of the codebase. Debugging prints don’t get enough credit.

marssaxman 2y ago

I used debuggers all the time when I used to work on interactive GUI applications. I am sure I could still remember how, if I had a need, but in the meantime I've spent years working on hardware drivers, embedded firmware, distributed systems, ML pipelines, and other such environments where debuggers would be unhelpful or impossible. Mostly I debug by looking at logs, and by thinking over their implications; you get used to it. Debugging is not really about the software, after all; it's a process of discovering the limits of your own understanding and identifying the flaws in your mental models. You make hypotheses and test them, and it doesn't matter so much what instruments you use to perform the tests, so long as you know how to think about the process systematically.

PaulHoule 2y ago
You can get all kinds of tools for debugging embedded systems, like https://onlinedocs.microchip.com/oxy/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B-en-US-4/GUID-2E228ACE-9E8D-4350-BB97-82CCC430629A.html https://onlinedocs.microchip.com/oxy/GUID-DDB0017E-84E3-4E77... of course if your problem is timing sensitive you have a problem. (A project to make a display controller for AVR-8 PoV displays got bogged down because of that)
- beardyw 2y ago
  Yes there are tools, but it would be interesting to find out how much they are used. How often is timing not a problem?
- marssaxman 2y ago
  I did use JTAG from time to time during that period of my career, but it was not as often useful as one might hope, usually as you say due to timing issues. I got really comfortable hooking up a serial port and streaming logs out at 9600 bps, or just clipping an LED or scope to a spare output and watching what it did. Then, sometimes it just didn't feel like it was worth the trouble of setting up the JTAG, when I knew I could turn it around in a minute with a simpler test.
  - PaulHoule 2y ago
    That was where I was heading with my display controller, except the 9600 bps wasn't good enough, the serial connection wasn't so reliable so I was trying to make a really simple protocol like HLDC [1] but life got in the way. If I ever get back to the project (putting an LED sign on the side of my car such that you might see some hearts and stars and stuff if you looked at it the right way) I might try testing the display controller in an emulator or put the strip on a pendulum or something so I can get a picture of it doing its thing. [1] https://en.wikipedia.org/wiki/High-Level_Data_Link_Control https://en.wikipedia.org/wiki/High-Level_Data_Link_Control

PaulHoule 2y ago

Plenty. The difference is I'm using commercial tools (PyCharm, WebStorm, and IntelliJ) that have visual debugging that works. Now gdb from the command line is great for what it is, but a lot of people who use open source toolchains find that "it just doesn't work" when it comes to debugging. Myself, I think tests and debugging go together like peanut butter and jelly. That is, you use tests to set up a situation you want to debug, then you run the debugger. When you're all done you have a test that proves the bug was fixed. It might be less of a problem in the C++ world but I really like being able to use the debugger to investigate a situation without touching the source code at all, since if you start hacking on the source code to add printfs and add other debugging hacks you often wind up checking in things accidentally that you shouldn't have, particularly when you're also making real changes to fix the bug. An arXiv paper [1] investigates those accidental commits and reveals that people do a lot of printf debugging of async callbacks since those can be hard to debug; they breakpoint just find in most environments but you never really know if they are going to run or not and I think a lot times they get called N times for harmless things before you get the one you want to breakpoint. (Maybe it's just me but I've never had good luck with conditional breakpoints) [1] https://arxiv.org/abs/2501.09892 https://arxiv.org/abs/2501.09892

ai-christianson 2y ago
> Myself, I think tests and debugging go together like peanut butter and jelly. That is, you use tests to set up a situation you want to debug The hardest things are the ones that come up in prod/after it is already deployed and there's no obvious error message or indication something is wrong. E.g. rn, I'm building a SWE agent (https://ra-aid.ai https://ra-aid.ai), and running it against SWE-bench lite. The processes will run for 5+ hours and then randomly hang. So for stuff like this, I rely heavily on: 1) Verbose logging 2) Tools that let you inspect/debug running processes, e.g. py-spy.

eternityforest 2y ago

Ability to use the debugger is one of my top priorities, I will often redesign an entire plan of it breaks the debugger (Either because it uses DSLs, or it's too strongly multi language, or it's not runnable locally on the desktop at all). Same for version control, linting, and formatting, I pretty much ignore technologies that don't integrate with all the modern dev tools most of us expect to have.