4 ms·

> Can you imagine debugging your C/C++/Rust/Go/... programs by adding printf everywhere and re-run the whole thing ? Yes, absolutely. This is my principal and

> Can you imagine debugging your C/C++/Rust/Go/... programs by adding printf everywhere and re-run the whole thing ? Yes, absolutely. This is my principal and nearly-exclusive method of debugging the distributed systems I work on all day.

zem 8y ago
same. i find a debugger useful for tracking down segfaults, but for debugging logic it's printf all the way.
groestl 8y ago
It's true that for distributed systems, logging tends to work better/is a necessary first step. I'd still want to invest in an extensive test harness though, if you can afford that luxury. Usually this enables productive debugging for distributed systems code, which pays of quickly.
- sagichmal 8y ago
  Agreed, a deterministic test harness is critical, especially when working on the inner components, like state machines.
- stcredzero 8y ago
  There was one network monitoring company that used Smalltalk, and Smalltalk's ability to very rapidly save the entire memory image. Basically, for exceptions, a snapshot of the server's state could be saved off in addition to the log, then brought up later, completely live, with a debugger on that very method. (Definitely a distributed system, running on other people's hardware in other people's data centers.) I worked at another company where we used a different kind of Smalltalk serialization to save the GUI's state in an auto-generated error email or log entry, so we could open the application in the exact same UI state when dealing with a bug.
smt88 8y ago
Most people aren't working on distributed systems though, so debuggers work fine for them
- merb 8y ago
  well it's hard to find a race condition with a debugger. sometimes it would just work with the debugger since you slow down the program or maybe halt on the wrong places.
  - teh_klev 8y ago
    Sure, but I'd argue that most developers aren't working with code day in and day out where race conditions are a concern.
    - merb 8y ago
      well it depends, I mostly try to create my code so that things can run in parallel. I also barley use a debugger, even for code that does not run in parallel, mostly because I'm used to make logging calls at the right places so that I can find issues way faster than with a debugger (most often I'm only run into hard issues or issues where a debugger will fail, i.e. build scripts -_-)
  - singlow 8y ago
    The point is that the debugger is an essential tool for debugging because in most cases it will do what you want and is faster. Most coding errors are not race conditions. I don't know why everyone must pipe in with the edge cases where a debugger might not work. In 99% of scenarios where you want to test some code in a development environment, setting breakpoint is the quickest way to see what is wrong. Log output is useful too, and you will probably use both. But, if you are a developer and don't have the ability to step through your code in a debugger, many problems will take much longer to fix.
haggy 8y ago
It depends what the issue is. I work on dys. systems almost exclusively and if you can reproduce locally, I can almost always run the project using multiple procs with a debugger attached to each one of them
kbenson 8y ago
It's often much faster to just print or dump some data to screen just to see where your assumptions have gone wrong. There's a point at which some bugs become more complex, or just aren't easily figured out from this method, but it's surprisingly quick and powerful when used in conjunction with a language in which doing so is quick and easy. Doing it in a project that requires a few minutes or more just to build can quickly change this equation, but this is my go-to initial method for debugging problems. Then again, it's generally pretty easy for me since I develop with liberal use of debug messages and dumping of data structures at multiple locations depending on the value of the DEBUG environment variable. In production I just run without a DEBUG environment prefix and nobody is bothered by the verboseness, but if there's a problem, step one is generally just doing a test run with DEBUG=3 or something prefixing the command. It's a bit different for web-based scripts like in PHP, but not much so (just make it a param), as long as STDERR goes to a log file.

zem 8y ago

same. i find a debugger useful for tracking down segfaults, but for debugging logic it's printf all the way.

groestl 8y ago

It's true that for distributed systems, logging tends to work better/is a necessary first step. I'd still want to invest in an extensive test harness though, if you can afford that luxury. Usually this enables productive debugging for distributed systems code, which pays of quickly.

sagichmal 8y ago
Agreed, a deterministic test harness is critical, especially when working on the inner components, like state machines.
stcredzero 8y ago
There was one network monitoring company that used Smalltalk, and Smalltalk's ability to very rapidly save the entire memory image. Basically, for exceptions, a snapshot of the server's state could be saved off in addition to the log, then brought up later, completely live, with a debugger on that very method. (Definitely a distributed system, running on other people's hardware in other people's data centers.) I worked at another company where we used a different kind of Smalltalk serialization to save the GUI's state in an auto-generated error email or log entry, so we could open the application in the exact same UI state when dealing with a bug.

smt88 8y ago

Most people aren't working on distributed systems though, so debuggers work fine for them

merb 8y ago
well it's hard to find a race condition with a debugger. sometimes it would just work with the debugger since you slow down the program or maybe halt on the wrong places.
- teh_klev 8y ago
  Sure, but I'd argue that most developers aren't working with code day in and day out where race conditions are a concern.
  - merb 8y ago
    well it depends, I mostly try to create my code so that things can run in parallel. I also barley use a debugger, even for code that does not run in parallel, mostly because I'm used to make logging calls at the right places so that I can find issues way faster than with a debugger (most often I'm only run into hard issues or issues where a debugger will fail, i.e. build scripts -_-)
- singlow 8y ago
  The point is that the debugger is an essential tool for debugging because in most cases it will do what you want and is faster. Most coding errors are not race conditions. I don't know why everyone must pipe in with the edge cases where a debugger might not work. In 99% of scenarios where you want to test some code in a development environment, setting breakpoint is the quickest way to see what is wrong. Log output is useful too, and you will probably use both. But, if you are a developer and don't have the ability to step through your code in a debugger, many problems will take much longer to fix.

haggy 8y ago

It depends what the issue is. I work on dys. systems almost exclusively and if you can reproduce locally, I can almost always run the project using multiple procs with a debugger attached to each one of them

kbenson 8y ago

It's often much faster to just print or dump some data to screen just to see where your assumptions have gone wrong. There's a point at which some bugs become more complex, or just aren't easily figured out from this method, but it's surprisingly quick and powerful when used in conjunction with a language in which doing so is quick and easy. Doing it in a project that requires a few minutes or more just to build can quickly change this equation, but this is my go-to initial method for debugging problems. Then again, it's generally pretty easy for me since I develop with liberal use of debug messages and dumping of data structures at multiple locations depending on the value of the DEBUG environment variable. In production I just run without a DEBUG environment prefix and nobody is bothered by the verboseness, but if there's a problem, step one is generally just doing a test run with DEBUG=3 or something prefixing the command. It's a bit different for web-based scripts like in PHP, but not much so (just make it a param), as long as STDERR goes to a log file.