>Print statements are "valid" in that they often work, but when a debugger is available it's almost always the right way to go.
I don't know about this one. I think that having to write print statements makes you do actual thinking about your debugging strategy and therefore makes you understand the flow of your code more. A debugger is certainly useful, but I was surprised the first time I had to go without one to find that I didn't miss it that much and possibly was even more efficient.
Debuggers are great and superior to print statements when they're usable. Use a debugger when you can. Sadly, it is increasingly the case that you cannot use a debugger when you want to use one.
Print statement binary search is primitive, but it's survived as a tool because it's almost universally applicable.
Debuggers are more efficient at locating and fixing specific bugs. However when you debug with print statements you get the opportunity to review the code and find bigger design problems that need to be fixed.
Furthermore, and more controversially, if you debug with debuggers, you will be driven to use programming techniques that are friendly to your debugger. But when you debug with print statements, you are free to use whatever programming techniques are best for human comprehension.
Now before you raise your keyboard and rush to disagree, consider carefully that the position I just described is agreed with by well-known programmers such as Linus Torvalds and Larry Wall. There are equally well-known programmers who disagree.
The true merits of the case are hard to determine. But if you think that one side is trivially wrong, then you should view this as a learning opportunity. Because you're certainly mistaken.
The only time I need to pull out a debugger is when I can't reason through the problem on my own (possibly with a couple print statements)
By and large, the only time I can't reason through the problem on my own is because the code in question is not properly unit tested, and it is complex to isolate the problem itself.
The only time it's worth my time to bring out the debugger is when the issue is so opaque as to require that level of in-depth investigation. I've spent days tracking down esoteric heap smashers in gdb.
However, most of the time, I just watch my unit test assertions fail, and then fix the issue.
Print Statements, basically a form of logging, can be superior to debuggers, too (especially "when they're usable" :-) )
IMO, all three: logging, printing and the debugger have their place. In theory, print statements could be 100% replaced by debugger macros or dtrace, but the tooling just is better (it is easier to keep your output the same across runs) for a class of "takes a couple of days to find" bugs.
Debuggers have features like watchpoints, which cannot be emulated in any form using print statements. Also, many codebases are not set up to provide a decent stack trace without using a debugger. Features like watchpoints allow you to think about the debugging process in a very different way and can turn many otherwise difficult bugs into 30-second fixes.
I don't know about this one. I think that having to write print statements makes you do actual thinking about your debugging strategy and therefore makes you understand the flow of your code more. A debugger is certainly useful, but I was surprised the first time I had to go without one to find that I didn't miss it that much and possibly was even more efficient.