4 ms·

This is often laughed at, but I think this is fine. Whatever helps debugging efficiently. And debuggers have their uses too. Printing is my usual way of debug

by jraph 4y ago

This is often laughed at, but I think this is fine. Whatever helps debugging efficiently. And debuggers have their uses too. Printing is my usual way of debugging. I use / switch between various languages that have unequal support for interactive debuggers with different interfaces, in various contexts where debuggers are not always usable. Printing / logging always works the same regardless of the language and the context. Step by step often looses me, and print forces to think about what and where to print so it also has its advantages. Interactive debugging has a big advantage: no need to recompile / reload each time you need to check out the value of a variable at a new location in the code. But yes, the fact I switch between languages and contexts seems to encourage me to use generic tools that work okay for every language and context instead of specialized tools, so Kate and printing it is. But you can become efficient anyway, and for a task where printing is not enough, you can always spin up the heavy tools.

horsawlarway 4y ago
> But you can become efficient anyway, and for a task where printing is not enough, you can always spin up the heavy tools. this exactly. Print based debugging is a great way to verify all sorts of assumptions, and it gives a wonderful order based view of execution very quickly. If that turns out not to be enough - by all means, break out the real debugging tools, but I'd wager 95% of the time, print based debugging will lead you to the answer more quickly and easily than spinning up gdb or inspect-brk or visual-studio or any of the other heavy weight tools. Not that those tools aren't incredible (I mean that so literally) - it's just that they're like bringing a back-hoe in to plant your tulip bulbs... it's complete overkill for answering questions like "Did this code even run?" or "how many times is this function getting called" or "is function a called before function b" and SO many other useful basic tests for my assumptions.
nunez 4y ago
Agreed. I forgot how to use gdb and windbg because it's been so long since I needed to grok assembly to troubleshoot something (you need to use gdb with Go too) and most of my work these days is with interpreted languages that are easy to reflect into, but its very useful knowledge to have in the toolbox.
userbinator 4y ago
Step by step often looses me, and print forces to think about what and where to print so it also has its advantages. This is a very good point. I have taught beginners before, and saw many of them would somehow open the debugger in their IDE, then start stepping through all their code absentmindedly, as if the mere act of doing so would somehow cause the bug to become apparent. By the time they see something wrong, they've already gone well past the point at which the first error was. I have called this phenomenon "debugger tunnel-vision". It seems like the debugger is more like a ritual to them, some sort of magic that will automatically find bugs quickly and easily, and they get immensely confused when that strategy obviously doesn't work. I turn them towards using prints, and many times they find the bug even before the next run of the program, while considering where and what to print. IMHO the "tool fetish" that some programmers have is actually counterproductive.
- oreally 4y ago
  Tools help you be more productive. The keystroke reduction in using debuggers far supercedes print debugging. Imo you've blamed tool fetish when it's really inexperience that is the problem.
  - throw827474737 4y ago
    You didn't get the point. My juniors work around fallout in some detail instead of solving the root cause or higher level systemic issue by just a little bit of thinking. Sure, there is the right time for a tool, but tbh all of my bugs are usually much quicker solved by thinking, understanding, unit tests with maybe a print than trying to catch something with breakpoints and stepping. And for the other nasty situations (think about concurrency, multiprocess, embedded irq handling) they are not even able to help but only professional tracing is (print-debugging always sounds so amateurish). So > Tools help you be more productive. The keystroke reduction in using debuggers far supercedes print debugging Sometimes yes, but in general I have seen those tools get into the way. For some reason I rarely need them and juniors often get mislead and don't see the forest for the trees.
  - d883kd8 4y ago
wccrawford 4y ago
There's only been a few times in my 15+ year career that the debugger would have gotten me to an answer faster than printing. I tried it, and got good enough at it to understand what it does for me, and I didn't prefer it. I really dislike these articles that look down on people for doing things their own way when that way isn't actually wrong. There's a lot going on when programming, and there's very rarely a decidedly wrong answer.
DangitBobby 4y ago
For me the big thing is that there is now a _written record_ of what happened that I can now reference and think about for as long as I want while looking at the code that produces it, which can really help me figure out what exactly is happening. I have found debuggers to be completely useless for understanding how a series of steps has gone subtly wrong, but very useful for figuring out what the fuck is in some giant object I know nothing about.

by jraph 4y ago

horsawlarway 4y ago

> But you can become efficient anyway, and for a task where printing is not enough, you can always spin up the heavy tools. this exactly. Print based debugging is a great way to verify all sorts of assumptions, and it gives a wonderful order based view of execution very quickly. If that turns out not to be enough - by all means, break out the real debugging tools, but I'd wager 95% of the time, print based debugging will lead you to the answer more quickly and easily than spinning up gdb or inspect-brk or visual-studio or any of the other heavy weight tools. Not that those tools aren't incredible (I mean that so literally) - it's just that they're like bringing a back-hoe in to plant your tulip bulbs... it's complete overkill for answering questions like "Did this code even run?" or "how many times is this function getting called" or "is function a called before function b" and SO many other useful basic tests for my assumptions.

nunez 4y ago

Agreed. I forgot how to use gdb and windbg because it's been so long since I needed to grok assembly to troubleshoot something (you need to use gdb with Go too) and most of my work these days is with interpreted languages that are easy to reflect into, but its very useful knowledge to have in the toolbox.

userbinator 4y ago

Step by step often looses me, and print forces to think about what and where to print so it also has its advantages. This is a very good point. I have taught beginners before, and saw many of them would somehow open the debugger in their IDE, then start stepping through all their code absentmindedly, as if the mere act of doing so would somehow cause the bug to become apparent. By the time they see something wrong, they've already gone well past the point at which the first error was. I have called this phenomenon "debugger tunnel-vision". It seems like the debugger is more like a ritual to them, some sort of magic that will automatically find bugs quickly and easily, and they get immensely confused when that strategy obviously doesn't work. I turn them towards using prints, and many times they find the bug even before the next run of the program, while considering where and what to print. IMHO the "tool fetish" that some programmers have is actually counterproductive.

oreally 4y ago
Tools help you be more productive. The keystroke reduction in using debuggers far supercedes print debugging. Imo you've blamed tool fetish when it's really inexperience that is the problem.
- throw827474737 4y ago
  You didn't get the point. My juniors work around fallout in some detail instead of solving the root cause or higher level systemic issue by just a little bit of thinking. Sure, there is the right time for a tool, but tbh all of my bugs are usually much quicker solved by thinking, understanding, unit tests with maybe a print than trying to catch something with breakpoints and stepping. And for the other nasty situations (think about concurrency, multiprocess, embedded irq handling) they are not even able to help but only professional tracing is (print-debugging always sounds so amateurish). So > Tools help you be more productive. The keystroke reduction in using debuggers far supercedes print debugging Sometimes yes, but in general I have seen those tools get into the way. For some reason I rarely need them and juniors often get mislead and don't see the forest for the trees.
- d883kd8 4y ago

wccrawford 4y ago

There's only been a few times in my 15+ year career that the debugger would have gotten me to an answer faster than printing. I tried it, and got good enough at it to understand what it does for me, and I didn't prefer it. I really dislike these articles that look down on people for doing things their own way when that way isn't actually wrong. There's a lot going on when programming, and there's very rarely a decidedly wrong answer.

DangitBobby 4y ago

For me the big thing is that there is now a _written record_ of what happened that I can now reference and think about for as long as I want while looking at the code that produces it, which can really help me figure out what exactly is happening. I have found debuggers to be completely useless for understanding how a series of steps has gone subtly wrong, but very useful for figuring out what the fuck is in some giant object I know nothing about.