> C++ code can quickly get unruly and ugly without diligence on the part of the programmers. To see how bad things can get, check out the STL source code. Microsoft's and GCC's[5] STL implementations are probably the ugliest source code I've ever seen. Even when programmers take extreme care to make their template code as readable as possible it's still a complete mess. Take a look at Andrei Alexandrescu's Loki library, or the boost libraries—these are written by some of the best C++ programmers in the world and great care was taken to make them as beautiful as possible, and they're still ugly and basically unreadable."
Finally, a guru dares to call a spade a spade. Header-only, template-only C++ programming is a mistake! After 1995 C++ Standardization took the wrong path and lost contact with real world developers. The glorification and idolization of 'STL programming' was in sharp contrast with programmer's needs. Today in C++ there is a chasm like in no other language between the 'official language' and what programmers need and use day in day out.
What's odd is that the C++ community fetishizes these techniques so much. I mean, when faced with problems that require running code at compile team, the lisp community's answer was "ok, just include an interpreter and run your lisp code at compile time with eval-when". The C++ community first insisted that there was never a reason for doing so and then said "ok, but instead of writing code for compile-time execution using C++, we're going to create an nightmarishly complex and crippled language that you'll use instead; it will be so painful that you'll be proud of implementing factorial".
And now a whole new generation of programmers can gaze at the horror of Modern C++ metaprogramming and conclude that metaprogramming is bad....
As far as I know, C++ templates were never intended be turing complete. They turned out that way by accident.
If you'd asked the standards body to add a turing complete type-level meta-programming language to C++ in order to generate code at compile time I suspect they'd have told you to get knotted.
What people actually asked for was a reasonable syntax for adding generic functions to C++ that would not carry any runtime cost. Sounds completely reasonable, right? The standards group said "sure, how about this?", and kept adding more perfectly reasonable individual requests to the syntax like template specialisation. Only afterwards did the true nature of crawling horror that they'd inadvertently unleashed become apparent.
Any style of programming can look like a mistake if you take it to crazy extremes. I find header/template C++ programming works very well provided you do it in moderation and keep things simple.
Remember the STL is complicated because it tries to be super generic, and it tries to be super generic because it's a library so it tries to cater for all possible uses. If you're writing a program instead of a library, you can make things orders of magnitude simpler because you only have to provide what you need, not everything any programmer on Earth might need.
Java Swing using anonymous classes to 10 or more depths to represent callbacks because OOP and inheritance > all.
Haskell having one file IO operation a thousand feet below the surface of a program "un-purifying" the entire call stack with side effects because pure functional is king.
Trying to implement any generic anything in C, because in procedural having template or inheritance based polymorphic behavior is crazy, so you end up with 5 million ways to write readNumber() for every numeric type ever.
So go figure, procedural, meta, functional and OOP all go completely deep end when you try to kitchen sink them as the be all end all solution to all problems and woes.
> Haskell having one file IO operation a thousand feet below the surface of a program "un-purifying" the entire call stack with side effects because pure functional is king.
And that's the way it should be. (Refator your programme, if you want to keep the other functions pure. But it is a Good Thing (TM), that you can not hide your IO if you pile on enough layers.) Haskell has other problems, though.
Bear in mind that the person making the comments you quoted is not actually John Carmack, who I will agree is a "guru". Carmack's own comments later indicate that the style represented in Doom 3 is an intermediate point in his personal evolution. Indeed, this style was a common one 10+ years ago and may have been appropriate for the less reliable compilers and buggier STL implementations of the day. It's certainly still popular with many programmers, though, as you imply in your last sentence...
Considering how many languages these days completely eschew the header/body paradigm, I'm not sure that "head-only" programming is such an obvious mistake.
Such languages tend to be reasonably smart about what changes trigger large recompiles, and about not re-parsing the same lines of header-only code over for every compilation unit. In C++ the best you can hope is to set up precompiled headers and live with the artificial dependencies.
If the only problem you have with header-only programming is compile times, might I humbly suggest that the problem you are actually concerned about is entirely somewhere else (hint: most language compilers are terribly unsmart about what changes trigger recompiles, as the cost of compiling the entire source tree isn't too terrible).
Finally, a guru dares to call a spade a spade. Header-only, template-only C++ programming is a mistake! After 1995 C++ Standardization took the wrong path and lost contact with real world developers. The glorification and idolization of 'STL programming' was in sharp contrast with programmer's needs. Today in C++ there is a chasm like in no other language between the 'official language' and what programmers need and use day in day out.