Came to comment this. Print debugging makes me so fast at work. Unless you give me an easier and better tool I so no reason to change. Works in every language, exactly how I'd expect, and is exceedingly easy to explain to others.
Print debugging makes me fast too, but there is eventually a breaking point (get it) where print debugging isn't getting me the answers I need and I have to switch to using other options like interactive debugging.
Are you under the impression that investing the time to learn to use a purpose-built debugger will be a net time loss?
I used to print-debug a lot, but since I started working with a stack where I use an IntelliJ derivative - that is to say, where the debugger actually works - and I'm never ever going back. It's better by a huge margin.
Yep. You can blow peoples minds in ANY LANGUAGE by using print debugging sometimes. It's amazing, but true. At least it's been that way for the ~25 years I've been doing it.
You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
> You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
You could just put a breakpoint there, look at as many values as you want, and not have to re-run it if you think of another.
There are a few languages where print debugging isn't as fast, but that always requires a ton of tooling. I found that debugging Java using Eclipse or Intellij was faster than printing, as I could introspect state and change values while the process was running. Similarly, some scripting environments I've used have allowed for robust state and flow analytics.
But in a normal environment ? or using C++ ? It's generally quicker (though much dirtier) to find simple bugs using print statements to track down assumptions ; when you're in the weeds with a complicated problem or need to track down a crash, then yes, bring out the big guns. But for normal development, I don't think it's completely necessary.
Debugging in C++, is a bit of a pain sometimes. GDB tools are good paired with an IDE like VSCode, but due to the abstractions in C++, inspecting variables require verbose code - beyond the convenience of debugging in a higher level language like Python or even Java as you suggested.
Eg: tracking the values of a std::vector isn't obvious, since there is std:begin and std::end iterators in the vector namespace and you have to manually dereference the whole range in the debugger.
spelunker|4 years ago
Still though, I reach for print debugging first.
occz|4 years ago
I used to print-debug a lot, but since I started working with a stack where I use an IntelliJ derivative - that is to say, where the debugger actually works - and I'm never ever going back. It's better by a huge margin.
NDizzle|4 years ago
You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
OJFord|4 years ago
> You think you're here? Let's put a few print statements in there to confirm your execution path is actually what you think it is, and those values are what you expect them to be.
You could just put a breakpoint there, look at as many values as you want, and not have to re-run it if you think of another.
necrotic_comp|4 years ago
But in a normal environment ? or using C++ ? It's generally quicker (though much dirtier) to find simple bugs using print statements to track down assumptions ; when you're in the weeds with a complicated problem or need to track down a crash, then yes, bring out the big guns. But for normal development, I don't think it's completely necessary.
thealig|4 years ago
Eg: tracking the values of a std::vector isn't obvious, since there is std:begin and std::end iterators in the vector namespace and you have to manually dereference the whole range in the debugger.