The compiler is always right... except when it isn't.
Really, the compiler is usually right. Fair enough. But I've run into compiler bugs, and that's just in internships! (And I'm not even counting the compiler I helped write...)
And sometimes the issue isn't even a bug but a design deficiency. Those are hard to deal with because they're real problems, but also exist for real reasons. I ran into one of these when compiling OCaml to JavaScript and getting stack overflows—turns out the compiler couldn't handle mutual recursion properly. And that's because it's a hard problem! And yet, it also meant the compiler was wrong.
Thinking about it, perhaps the title could be read as "the compiler is always right, even when it's wrong". Just like the ultimate arbiter in a car crash is momentum, not the rules of traffic, if you hit a compiler bug, "fixing" your program is probably much easier than fixing the compiler—even if you're in the right! That's what we ended up doing with js_of_ocaml, by choosing a different backend for our parser generator that didn't create mutually recursive code.
To be fair, the original author does acknowledge at the end that the title is hyperbole.
Still, given that the compiler almost always seems to be right in these cases, it’s surprising just how often even our trusty C compilers do have bugs. There is at least one well established project trying to formally verify a compiler to prevent that problem, apparently with considerable success already:
Having once spent a lot of time trying to track down a bug in some floating point code, only to find that the optimizer had tried to use one more floating point register than it actually had available something like ten levels down the call stack from where the error was being observed, I wish such projects the best of luck and look forward to a time when all our development tools are similarly trustworthy.
i think in this context, the author is referring to mainstream (gnu, ms, intel) compilers, that are very mature and have thousands of tests that they must pass to be eligible for release.
writing a compiler is tricky, and it is almost an absolute certainty that it will have a bug :)
I don't mean to pick on MSVC and many of those are not-yet-implemented issues, it is just the easiest to search for. I've found (and even fixed a few) enough bugs in LLVM/Clang to realize that no compiler is perfect or even close! =)
I think that js_of_ocaml 2.0 added support for compiling mutually recursive functions using trampolines. So that compiler is back to being right again.
Really, the compiler is usually right. Fair enough. But I've run into compiler bugs, and that's just in internships! (And I'm not even counting the compiler I helped write...)
And sometimes the issue isn't even a bug but a design deficiency. Those are hard to deal with because they're real problems, but also exist for real reasons. I ran into one of these when compiling OCaml to JavaScript and getting stack overflows—turns out the compiler couldn't handle mutual recursion properly. And that's because it's a hard problem! And yet, it also meant the compiler was wrong.
Thinking about it, perhaps the title could be read as "the compiler is always right, even when it's wrong". Just like the ultimate arbiter in a car crash is momentum, not the rules of traffic, if you hit a compiler bug, "fixing" your program is probably much easier than fixing the compiler—even if you're in the right! That's what we ended up doing with js_of_ocaml, by choosing a different backend for our parser generator that didn't create mutually recursive code.