>>74
But why "optimized" in straight contrast with "flexible and generic"? Specially, why "prematurely" optimized? I see these design decisions as simply the most natural, direct and even simple way to implement some functionalities. I don't see them as premature optimizations. For example, I would categorize some ridiculous C++ idioms such as CRTP into the "premature optimization" moniker, but in general, C++'s execution model is just extremely simple, not "prematurely optimized". These decisions are not performance-driven.
Just to illustrate my point, one could argue that garbage collecting, multimethods and other things you've mentioned are just "premature flexibility". I have faced just very few situations in which I really needed things like that, for projects of different nature.
Not that these things are bad, much for the contrary: they're good tools when applied in the correct problems. C++ simply opted not to impute these tools to
every program beforehand. And many, if not all, of them can be implemented, nonetheless, in C++, with the particular advantage (if it could be said so) that the programmer
knows these things are present in their program, and exactly where they are, if it matters to him. I understand that syntax is not just sugar and, for example, while lambdas cannot be compared with functors, since they're much more expressive and syntactically easy to manipulate, functors usually fill in well the gap lambdas were supposed to fill, and these objects fit even better (in my opinion) with the overall rest of the language. And these features can be implemented in different ways, with different goals in mind. This is a very important degree of "flexibility and genericity", in my opinion, which is often overlooked because they don't come in the shape people are used to.
And lastly, well, C++ surely isn't easy for compilers. It is possibly the most difficult language to parse and to optimize; that's why compilers fail so badly in providing good, human-level responses and results to the user.