3 ms·

That is an... odd statement. The debugger is what enables me to understand what exactly is going on. Noone, not even you, will be able to fully grasp any modern

That is an... odd statement. The debugger is what enables me to understand what exactly is going on. Noone, not even you, will be able to fully grasp any modern language and framework, and the debugger becomes a necessity. As a counter claim: In my experience, programmers that don't use debuggers, are those that have difficulties understanding things. They just throw code at it until something sticks.

loup-vaillant 10y ago
I hardly eve use debuggers. But I do understand stuff. Last week I found a small bug in the reference implementation of Argon2i (Found out by implementing my own). Last year, I designed and implemented a small programming language (for work, with deadlines money and all). I did the VM in C++, and the bytecode compiler in Ocaml (tried C++ first, it was too cumbersome at recursive data structures). To understand what's wrong with my program, I need a strong understanding of the data it manipulates. Show me the data, and I can probably track down the bug. The sequence of operations shown by step-by-step debugging is important, but never helped me as much. I have invariants in mind, and I can detect invariant violations by looking at the data, not at the operations between them. In practice it means I use Valgrind first to weed out most undefined behaviours, then printf(). Yep, printf(). Take my VM for example. Had many bugs, many of them hard to track: off-by-one errors were not detectable by Valgrind for instance, because my VM heap was a giant std::vector<Word>. The GC was wrong, the stack management was wrong, the primitives were wrong… I made errors pretty much everywhere. What saved me was a little printf() based visualization tool. I could now see every block in my heap, and if anything went wrong there, I would detect it very quickly. This became my new Valgrind. I have no idea how gdb would have helped me there. Didn't need it anyway.
- carussell 10y ago
  Your comment only makes sense if you equivocate on the definition of debugger. Debugging by printf is not the same thing as not using a debugger.
  - loup-vaillant 10y ago
    There are two ways to put it: I can say "I don't need a debugger, I have printf", or I can say "I don't need gdb, printf is my debugger". Either is fine. Most conversations about debuggers however tend to equate the debugger with something like gdb or the IDE debugging interface. People will often say the absence of such a debugger is a deal breaker for them. It feels like they forgot about printf.
    - emsy 10y ago
      I also distinct between people that use a debugger to find problems in code and people that use the debugger to write code in the first place. The latter are the ones I've criticised in my original comment. I expected to receive many downvotes on this comment because most mediocre programmers I know rely heavily on the debugger for programming.
    - deleted 10y ago
      [deleted]

loup-vaillant 10y ago

I hardly eve use debuggers. But I do understand stuff. Last week I found a small bug in the reference implementation of Argon2i (Found out by implementing my own). Last year, I designed and implemented a small programming language (for work, with deadlines money and all). I did the VM in C++, and the bytecode compiler in Ocaml (tried C++ first, it was too cumbersome at recursive data structures). To understand what's wrong with my program, I need a strong understanding of the data it manipulates. Show me the data, and I can probably track down the bug. The sequence of operations shown by step-by-step debugging is important, but never helped me as much. I have invariants in mind, and I can detect invariant violations by looking at the data, not at the operations between them. In practice it means I use Valgrind first to weed out most undefined behaviours, then printf(). Yep, printf(). Take my VM for example. Had many bugs, many of them hard to track: off-by-one errors were not detectable by Valgrind for instance, because my VM heap was a giant std::vector<Word>. The GC was wrong, the stack management was wrong, the primitives were wrong… I made errors pretty much everywhere. What saved me was a little printf() based visualization tool. I could now see every block in my heap, and if anything went wrong there, I would detect it very quickly. This became my new Valgrind. I have no idea how gdb would have helped me there. Didn't need it anyway.

carussell 10y ago
Your comment only makes sense if you equivocate on the definition of debugger. Debugging by printf is not the same thing as not using a debugger.
- loup-vaillant 10y ago
  There are two ways to put it: I can say "I don't need a debugger, I have printf", or I can say "I don't need gdb, printf is my debugger". Either is fine. Most conversations about debuggers however tend to equate the debugger with something like gdb or the IDE debugging interface. People will often say the absence of such a debugger is a deal breaker for them. It feels like they forgot about printf.
  - emsy 10y ago
    I also distinct between people that use a debugger to find problems in code and people that use the debugger to write code in the first place. The latter are the ones I've criticised in my original comment. I expected to receive many downvotes on this comment because most mediocre programmers I know rely heavily on the debugger for programming.
  - deleted 10y ago
    [deleted]