That post quotes people like Rob Pike saying that stepping line-by-line is a crutch, that instead you should be able to reason about code. And that's true, if you understand what you are doing completely.
But in the real world, you never do. Programmers are constantly forced to stretch and use unfamiliar languages. Worse yet, they are forced to use unfamiliar libraries. Documentation sucks, there's no possible way to understand APIs than to step through code -- either watching the returned values, or compiling their source and stepping into it.
As an experienced programmer, it's true I often don't step through every line. The lines I understand completely, the ones I can fully reason about, I don't bother. But the programmer spends only a small percentage of their time on things they understand -- most of the time spent coding is noodling on the things they don't understand, and that's where the debugger comes in.
And this doesn't even take into account that in the real world, where programmers spend a lot of time working on other people's code. Sometimes the only way to figure it out is to set a breakpoint and run the unit test until it reaches that point.
Programmers fetishize editors. Real programmers, those who produce a lot of code, fetishize debuggers, both the one built into the IDE for debugging working code, and also the specialized tools for diagnosing problems in buggy code.
I take the contrary position -- aggressive use of a debugger gives you insight you won't get by mere inspection. https://t.co/U81C80tR88— John Carmack (@ID_AA_Carmack) June 22, 2016
What does using a debugger have to do with creating a visual studio project?
Different people have different tastes. Live and let live. My only concern is for those who rely on debugging ~too~ much and end up very lost when moving to a more functional style. Debugging is inherently imperative.
I agree with Rob here
Post a Comment