Chris, I actually honor a good rant and yours even taught me two new words (obtuse and prowess), which alone made my day. I also think, that you are right about people using template programming just because it is en vogue.

I for example remember a colleague solving a quite simple task with templates and function pointers, leading to nearly unreadable code. Since the template functions had to be specialized for each type, there was no code reuse, and when I refactored it, I came up with five static functions each of which contained about 10 lines of code. Even OO would have been overkill here...

However, policy based design can be effective. An example: Our applications all use a core system that offers several kinds of containers (maps, vectors, lists), for several types (Instances, Links). They all do the same, but they all do it a little bit different. Using templates and PBD, I managed to refactor about 90% of the functionality into one class. About five different implementations of iterators were reduced to one template class (which consists of six really simple functions having an average of five lines of code) and two policy classes (that contain just two lines of code). Which actually is a good thing, since it makes the code more clear and easier to maintain.

Anyhow, extensive use of templates with lot's of parameters and template template parameters surely turns your code into a monster. And since it isn't even properly debuggable, it is a monster without a cage. I agree with Len here: Don't try this at home.

I agree that template meta programming can be useful and the stuff in it's just that Alexandrescu’s book is interesting and thought provoking. BUT it's an idiom that many people are currently unfamiliar with and it's also an idiom that many people are keen to play around with, because of this I'd need some solid justification of why it's being used before I'd want to see it in a normal production system. Right now many uses of meta programming seem to fit into the "doing clever things just to be clever" category and I prefer to see production code that's as simple as it can be...

By the way I completely agree with you that the design is more important than optimisation. Design it, test it, profile it, optimise it - and you usually wont need the last one but if they design was good then it should be relatively easy to isolate the code that needs optimising and replace it with something faster - and by the time you do that you already have the tests that you wrote for the original version to make sure that your faster version still actually does the right thing.

I know I quickly threw this off, but this is a topic that has been on my mind for a year. I wanted to stir up a bit of controversy. Isn't that what blogging is all about? I have a more complete article on this, but I have been having a difficult time getting it through the powers that be, so some of that frustration came out here. The revision process has sucked the voice out of my article.

I am not a fan of template based PDB. It does have applications, but I feel they are limited. You loose the interface specification for the policy. This is a problem with C++. It lacks concept checking. I personally think concept checking and specification is vital, and with out, I almost always avoid PDB with templates.

I've heard Alexandrescu speak a couple times on PDB, and he always brings up the performance issue. But there is no performance issue. And I argue that it can hurt performance.