4 ms·

When first learning to program, my teacher refused to allow us to use the debugger. He believed it corrupted our abilities to truly understand the code that we

When first learning to program, my teacher refused to allow us to use the debugger. He believed it corrupted our abilities to truly understand the code that we wrote. Although I now use a debugger, I can't help but feel improper for having abandoned his rule. While a debugger provides for an easier programming experience, there is something to be said for personally combing through every line of code to find a bug.

xg15 10y ago
To provide a counter point, I feel that I learned a lot by reading the code of the Java standard library and stepping through its code. Especially in light of excessive indirection, reflection and others that were ironically created to produce "easier to read" code, I think it can be really helpful to see what the code is actially doing. I can't relate to the argument of the teacher. To me, "understanding" a device means to be confident in what actions to the device will result in what consequences - and what internal processes are responsible for it. I'd think getting as much feedback as possible on your commands can only be helpful for that - and forbidding a debugger seems to me like artificially hiding what is "really" happening and denying feedback that would be readily available.
Terr_ 10y ago
I dunno, I mean, I'm sure you could learn to build internal combustion engines through trial and error, assembling them, letting them run, listening, stopping them, and opening them up again... ... But wouldn't it be even better to learn by assembling one with transparent materials and a magic device that could "pause" the whole engine at an arbitrary point in time? While it's true that it will enable some students to simply "fiddle until it works" without understanding, I think that's a small price to pay for the benefit it brings to the genuinely-curious students.
- banku_brougham 10y ago
  here is the crux, for me. understanding the thermodynamics of gases and mechanical properties of steel are what help you build a combustion engine. i think this is the point of the article, that stepping through code doesnt help you understand why things happen. when you know that pressure is proportional to the temperature and the inverse of the volume, and that steel yields at 36K psi, you understand why the piston shaft keeps breaking. those transparent materials and magic devices lets you watch the engine block crack in slow motion -- do they help you learn why that happened?
  - xg15 10y ago
    You need to know those properties. But they are usually a strong simplification of reality. They will help you not to completely botch your engine design. But the see-through engine could also show you that your particular design of the pipes leads to pressure being above threshold at that particular point - and can give you clues to investigate further. Which I think is why the closest equivalent to magic see-through engines - simulations - are actually used in engine design.

xg15 10y ago

To provide a counter point, I feel that I learned a lot by reading the code of the Java standard library and stepping through its code. Especially in light of excessive indirection, reflection and others that were ironically created to produce "easier to read" code, I think it can be really helpful to see what the code is actially doing. I can't relate to the argument of the teacher. To me, "understanding" a device means to be confident in what actions to the device will result in what consequences - and what internal processes are responsible for it. I'd think getting as much feedback as possible on your commands can only be helpful for that - and forbidding a debugger seems to me like artificially hiding what is "really" happening and denying feedback that would be readily available.

Terr_ 10y ago

I dunno, I mean, I'm sure you could learn to build internal combustion engines through trial and error, assembling them, letting them run, listening, stopping them, and opening them up again... ... But wouldn't it be even better to learn by assembling one with transparent materials and a magic device that could "pause" the whole engine at an arbitrary point in time? While it's true that it will enable some students to simply "fiddle until it works" without understanding, I think that's a small price to pay for the benefit it brings to the genuinely-curious students.

banku_brougham 10y ago
here is the crux, for me. understanding the thermodynamics of gases and mechanical properties of steel are what help you build a combustion engine. i think this is the point of the article, that stepping through code doesnt help you understand why things happen. when you know that pressure is proportional to the temperature and the inverse of the volume, and that steel yields at 36K psi, you understand why the piston shaft keeps breaking. those transparent materials and magic devices lets you watch the engine block crack in slow motion -- do they help you learn why that happened?
- xg15 10y ago
  You need to know those properties. But they are usually a strong simplification of reality. They will help you not to completely botch your engine design. But the see-through engine could also show you that your particular design of the pipes leads to pressure being above threshold at that particular point - and can give you clues to investigate further. Which I think is why the closest equivalent to magic see-through engines - simulations - are actually used in engine design.