3 ms·

“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compile

by Cpoll 9y ago

“It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time. > When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.

arghwhat 9y ago
Laziness invites efficiency. I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes. "It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter. Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art. "It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging. Teach proper debugging techniques instead of lying to others, or yourself.
sly010 9y ago
> Even thinking "it could be a compiler error" invites laziness. Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.
- Cpoll 9y ago
  Or worse it could deter curiosity and now you are spending time complaining about compiler bugs instead of debugging your code. If it's really a compiler bug, you'll find out in the process of debugging your code.

by Cpoll 9y ago

arghwhat 9y ago

Laziness invites efficiency. I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes. "It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter. Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art. "It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging. Teach proper debugging techniques instead of lying to others, or yourself.

sly010 9y ago

> Even thinking "it could be a compiler error" invites laziness. Or worse it could invite curiosity and now you are spending time wondering how could you tell if it's a compiler bug and how would you go about debugging it.

Cpoll 9y ago
Or worse it could deter curiosity and now you are spending time complaining about compiler bugs instead of debugging your code. If it's really a compiler bug, you'll find out in the process of debugging your code.