> For one thing, templates hurt the C++ compiler's ability to generate efficient code. This claim needs some support. C++ has notoriously slow compile times,

> For one thing, templates hurt the C++ compiler's ability to generate efficient code. This claim needs some support. C++ has notoriously slow compile times, but note that he's talking about efficiency of the code generated, not the efficiency of code generation itself, which I agree is damaged by templates. > It might surprise you to hear that, considering that C++ is "efficient" while functional languages like ML and Scheme are "inefficient," but it's true. C++ templates hide your intentions from the compiler: did you mean type abstraction? Did you mean a syntax extension? Did you mean constant-folding or compile-time code generation? The compiler doesn't know, so it has to just blindly apply the copy-and-paste strategy and then see what happens. I'm going to propose that this isn't a bug, it's a feature. The optimizer should be completely independent of syntax - and that's what C++ templates are, automatic AST expanders (plus some compile-time computation). All that the optimizer sees in the end are basically unrolled assembly instructions or IR, and we have battle-tested techniques to optimize this. Most of the heavy-duty optimizations in modern industrial compilers happen on the linear IR representation anyway. While templated code can be fatter than non-, link-time optimization can often reduce bloat when your your ad-hoc polymorphic template is really just acting as a parametric-polymorphic function a la ML. Now that I've played devil's advocate, someone more familiar with GHC, please tell me how Haskell has optimizations (e.g. deforestation? or is that just a solution for a problem that is specific to Haskell in the first place?) that make my assertions above untrue :)