3 ms·

So what do you use for debugging?

by aappleby 2mo ago

yurishimo 2mo ago
Printf works just fine in a lot of languages and domains. Not everyone likes to use a step debugger.
- not_kurt_godel 2mo ago
  I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
  - tonyedgecombe 2mo ago
    It feels like the option for people who are too lazy to learn their tools to me.
  - tstrimple 2mo ago
    The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
    - not_kurt_godel 2mo ago
      Step debuggers don't "create Heisenbugs", you're just much more likely to notice race conditions while step debugging than print debugging. If anything, print debugging creates more bugs because you're altering the code you're trying to test by definition.
      - tstrimple 1mo ago
        Step debuggers can 100% cause or hide race conditions that are exposed via other mechanisms. Especially in multi-threaded apps as I stated. If you've never encountered it, I'd suggest you've never debugged really nasty race conditions or serious bugs.
        not_kurt_godel 23d ago
        I have encountered the behavior you are describing too many times to count and then some. Of course step debuggers are going to expose and hide race conditions. In fact, exposing them is often the explicit purpose of using a step debugger in the first place. If you don't have a mental model of your code that includes conceptually separating the actual system behavior from the artificial debugging conditions, then you are correct, a step debugger is not going to be much use to you. Print debugging will help you limp along by virtue of letting you stab a little more accurately in the dark, but ultimately it's usually just punting the actual bug down the line until someone who understands the code more deeply is forced to fix it properly.

So what do you use for debugging?

yurishimo 2mo ago

Printf works just fine in a lot of languages and domains. Not everyone likes to use a step debugger.

not_kurt_godel 2mo ago
I would estimate print debugging is usually twice the work for 30% of the effectiveness of step debugging. It's the screwdriver to step debugging's drill. Fundamental and absolutely necessary sometimes but not the first tool you should be reaching for unless there's a specific reason.
- tonyedgecombe 2mo ago
  It feels like the option for people who are too lazy to learn their tools to me.
- tstrimple 2mo ago
  The specific reason I reach for print debugging first is it works literally everywhere across all technology stacks. I regularly work with different projects written in different languages. Printing works across all of them and the logs are easy to aggregate across different parts of the stack (microservices or other service composition patterns) giving you a broader range of data than you typically get from a step debugger. I've personally found that step debuggers are more likely to create Heisenbugs. Especially in multi-threaded applications or dealing with race conditions.
  - not_kurt_godel 2mo ago
    Step debuggers don't "create Heisenbugs", you're just much more likely to notice race conditions while step debugging than print debugging. If anything, print debugging creates more bugs because you're altering the code you're trying to test by definition.
    - tstrimple 1mo ago
      Step debuggers can 100% cause or hide race conditions that are exposed via other mechanisms. Especially in multi-threaded apps as I stated. If you've never encountered it, I'd suggest you've never debugged really nasty race conditions or serious bugs.
      - not_kurt_godel 23d ago
        I have encountered the behavior you are describing too many times to count and then some. Of course step debuggers are going to expose and hide race conditions. In fact, exposing them is often the explicit purpose of using a step debugger in the first place. If you don't have a mental model of your code that includes conceptually separating the actual system behavior from the artificial debugging conditions, then you are correct, a step debugger is not going to be much use to you. Print debugging will help you limp along by virtue of letting you stab a little more accurately in the dark, but ultimately it's usually just punting the actual bug down the line until someone who understands the code more deeply is forced to fix it properly.