Honestly, I feel like the print vs. debugger debate isn't about the tool, it's about the mindset. Print statements feel like you're just trying to patch a leak, while the debugger is about understanding the plumbing. I’m starting to think relying only on print is a symptom of not truly wanting to understand the system you're working in.

▲

someone_jain_ 5 days ago | parent | next [-]

https://lemire.me/blog/2016/06/21/i-do-not-use-a-debugger/

A bit of counterpoint here

	▲	willtemperley 4 days ago \| parent [-]
		I'm unconvinced with this article. Whilst obviously a smart guy, I don't think Lemire really works on the same problems most of us do. Looking at his posts and publications it's generally high peformance work on problems that are small in scope. I suspect most people actually work on far bigger projects than he does! Neither do I see from that arctile that he's actually used a modern debugger to its full potential. I rarely step through code in slow motion, but sometimes it's great to see program state. If there are thousands of files in a project I don't know well, I can put breakpoints to test hypotheses about my understanding.

▲

kstrauser 5 days ago | parent | prev | next [-]

Interesting POV. I see it exactly the opposite: using a debugger most of the time feels like trying to see the current state of things without understanding what set of inputs led to it. Print debugging feels more like trying to understand the actual program logic that got us to this point, based on a few choice clues.

I’m not saying you’re wrong or I’m right, just that we have diametric opposite opinions on this.

▲

ahartmetz 5 days ago | parent | prev [-]

Call stacks and reading code give very different views of the codebase. The debugger tells you what's happening, reading tells you what can happen in many situations at once. You can generalize or focus, respectively, but their strengths and weaknesses remain.

Readable code, though, is written with the reading view in mind.