> Anybody who uses a pow call to square a number must believe compilers are magic.
I'm guessing he thought using a temporary variable would look less pretty, and had no idea of the relative costs of imul and ipow.
> Compilers should be dumb, fast and predictable instead.
I don't care too much about dumb or fast, but they definitely need to be predictable. Even with something as low-level as C++ or Fortran, you often have to profile and disassemble to see if the compiler is doing the optimizations you want (e.g. unrolling loops, inlining functions, propagating constants, using SSE), or if you have to hold its hand. Trying to predict whether something as high-level as GHC will do what you want, or to figure out how to make it do so, is an absolute nightmare.
Yes, but it's nice to be able to predict what your compiler of choice will do, or at least to know that all of the things it might do will have similar performance. When you depend upon certain optimizations, you need to diagnose the compiler's failure to do them. This usually means knowing both how to read assembly, and how to force the compiler to do what you want.
This doesn't matter when any correct program is "good enough," but it matters a whole lot when failure to perform specific optimizations makes a program unacceptably slow.
I'm guessing he thought using a temporary variable would look less pretty, and had no idea of the relative costs of imul and ipow.
> Compilers should be dumb, fast and predictable instead.
I don't care too much about dumb or fast, but they definitely need to be predictable. Even with something as low-level as C++ or Fortran, you often have to profile and disassemble to see if the compiler is doing the optimizations you want (e.g. unrolling loops, inlining functions, propagating constants, using SSE), or if you have to hold its hand. Trying to predict whether something as high-level as GHC will do what you want, or to figure out how to make it do so, is an absolute nightmare.