5 ms·

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty print

I'm with Walter on this one. He's right. When I printf-debug, I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view. For example, right now I'm working with DFAs, and if I just printed out its transition table as it is in memory, it would be unreadable. Instead, I have a custom fmt::Debug impl that pretty prints something I can read and comprehend. I don't think I'd say this is the only reason I use printf instead of a debugger, but it's definitely a compelling one.

saagarjha 8y ago
I mean, why can't you just call that in the debugger when you need it?
- burntsushi 8y ago
  Why spin up a debugger when I can just printf it? :-) As others have mentioned, how do debuggers fair on optimized builds? Most of my time "debugging" is specifically spent on optimized builds looking at performance issues.
  - saagarjha 8y ago
    > Why spin up a debugger when I can just printf it? Xcode launches into a debugger by default, so it's not really an extra step for what I usually do. > As others have mentioned, how do debuggers fair on optimized builds? Not well, if you are planning to have variable names and stepping work correctly. > Most of my time "debugging" is specifically spent on optimized builds looking at performance issues. Sounds like a job for a profiler?
    - burntsushi 8y ago
      > Sounds like a job for a profiler? Sometimes yes. Sometimes no.
    - steveklabnik 8y ago
      > Sounds like a job for a profiler? Consider the similarities between profilers and printf debugging; both of them run your code, and spit out some kind of log, whereas debuggers stop your code in the middle of execution. Workflow wise, they're pretty much the same, even if their objectives are a bit different.
- pjmlp 8y ago
  Borland even used to have a few marketing ads about JIT debugging, by making use of Dr. Watson infrastructure on Win16.
forrestthewoods 8y ago
> I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view [...] I can read and comprehend. This isn't an argument in favor of printf over debugging. It's an argument in favor of making debuggers not suck! Visual Studio has decent watch-window formatters for STL containers. Vectors and Lists are easy. But it also has nice views into unordered_map and unordered_set. Visual Studio has a .natvis file format for adding custom debugger displays for custom datatypes [1]. If you're broken into the debugger and all threads are paused then a good debugger should be able to display your data however you like. Hell, it could have different display options to choose from if you really wanted! I also find myself regularly relying on printf to debug. But I view this as a failing of the debugger, rather than the superiority of printf. [1] I think the natvis format kinda sucks and is not sufficiently powerful. But that's a separate issue.
- burntsushi 8y ago
  I don't use C++ and I don't use Visual Studio. And even if I did, it would be pretty annoying to have to define debugger specific files just to print my data types. In Rust, I just add a fmt::Debug impl and now everyone who uses my code benefits from it, whether in a debugger (by calling that impl) or by print-debugging. I'm not here to convince anyone to use printf debugging. I don't care about some grand "argument" in favor of it over something else. What I care about are the tools available to me and the most effective way to debug, has historically, for me, been to use printf. This does not mean I only use printf. This does not mean I hate debuggers. This does not mean that I think debuggers are useless. This does not mean that I think debuggers couldn't or shouldn't be improved. This does not mean that I don't use profilers when debugging performance issues. All it means is that my tool of choice for every day debugging is printf. It is a convenient for me on a number of different dimensions. That there could exist a theoretically better tool sounds like a great reason for someone to go out and build something. But that someone isn't me, at least not right now.
  - forrestthewoods 8y ago
    I'm familiar with your work. I use ripgrep daily, thanks! > I mostly use printf. A debugger is only good for telling you where it seg faulted and the stack trace. That was Walter's statement, with which you agreed, and with which I strongly disagree. Maybe I overgeneralized. The Rust debugger story indeed sucks and I mostly use printf! I interpreted "a debugger is only good for..." to be all debuggers. And I don't think that's true. Which is why I gave a Visual Studio/C++ example. 2019 won't be the year Rust's IDE story gets good. But maybe 2020? People are laying the groundwork. I'm hopeful.
the_why_of_y 8y ago
With current gdb (i.e. released this decade), you can define pretty-printers in Python that are loaded automatically and print whatever you think is most important for a given type; the "print /r" command is available to print the raw details when necessary. libstdc++ ships with pretty-printers for its types. But I agree that printf debugging still has its uses.

saagarjha 8y ago

I mean, why can't you just call that in the debugger when you need it?

burntsushi 8y ago
Why spin up a debugger when I can just printf it? :-) As others have mentioned, how do debuggers fair on optimized builds? Most of my time "debugging" is specifically spent on optimized builds looking at performance issues.
- saagarjha 8y ago
  > Why spin up a debugger when I can just printf it? Xcode launches into a debugger by default, so it's not really an extra step for what I usually do. > As others have mentioned, how do debuggers fair on optimized builds? Not well, if you are planning to have variable names and stepping work correctly. > Most of my time "debugging" is specifically spent on optimized builds looking at performance issues. Sounds like a job for a profiler?
  - burntsushi 8y ago
    > Sounds like a job for a profiler? Sometimes yes. Sometimes no.
  - steveklabnik 8y ago
    > Sounds like a job for a profiler? Consider the similarities between profilers and printf debugging; both of them run your code, and spit out some kind of log, whereas debuggers stop your code in the middle of execution. Workflow wise, they're pretty much the same, even if their objectives are a bit different.
pjmlp 8y ago
Borland even used to have a few marketing ads about JIT debugging, by making use of Dr. Watson infrastructure on Win16.

forrestthewoods 8y ago

> I very much do not want to necessarily see the raw in-memory details. I want to see a pretty printed view [...] I can read and comprehend. This isn't an argument in favor of printf over debugging. It's an argument in favor of making debuggers not suck! Visual Studio has decent watch-window formatters for STL containers. Vectors and Lists are easy. But it also has nice views into unordered_map and unordered_set. Visual Studio has a .natvis file format for adding custom debugger displays for custom datatypes [1]. If you're broken into the debugger and all threads are paused then a good debugger should be able to display your data however you like. Hell, it could have different display options to choose from if you really wanted! I also find myself regularly relying on printf to debug. But I view this as a failing of the debugger, rather than the superiority of printf. [1] I think the natvis format kinda sucks and is not sufficiently powerful. But that's a separate issue.

burntsushi 8y ago
I don't use C++ and I don't use Visual Studio. And even if I did, it would be pretty annoying to have to define debugger specific files just to print my data types. In Rust, I just add a fmt::Debug impl and now everyone who uses my code benefits from it, whether in a debugger (by calling that impl) or by print-debugging. I'm not here to convince anyone to use printf debugging. I don't care about some grand "argument" in favor of it over something else. What I care about are the tools available to me and the most effective way to debug, has historically, for me, been to use printf. This does not mean I only use printf. This does not mean I hate debuggers. This does not mean that I think debuggers are useless. This does not mean that I think debuggers couldn't or shouldn't be improved. This does not mean that I don't use profilers when debugging performance issues. All it means is that my tool of choice for every day debugging is printf. It is a convenient for me on a number of different dimensions. That there could exist a theoretically better tool sounds like a great reason for someone to go out and build something. But that someone isn't me, at least not right now.
- forrestthewoods 8y ago
  I'm familiar with your work. I use ripgrep daily, thanks! > I mostly use printf. A debugger is only good for telling you where it seg faulted and the stack trace. That was Walter's statement, with which you agreed, and with which I strongly disagree. Maybe I overgeneralized. The Rust debugger story indeed sucks and I mostly use printf! I interpreted "a debugger is only good for..." to be all debuggers. And I don't think that's true. Which is why I gave a Visual Studio/C++ example. 2019 won't be the year Rust's IDE story gets good. But maybe 2020? People are laying the groundwork. I'm hopeful.

the_why_of_y 8y ago

With current gdb (i.e. released this decade), you can define pretty-printers in Python that are loaded automatically and print whatever you think is most important for a given type; the "print /r" command is available to print the raw details when necessary. libstdc++ ships with pretty-printers for its types. But I agree that printf debugging still has its uses.