The C++ Programming Language (B. Stroustrup)

Sometimes the inventor of a specific thing is the best person to explain it. There is no better way to learn about relativity than to go back to the original article written by Einstein; how better could anyone explain the value of existentialism than Sartre; Kernighan and Ritchie did a wonderful job at explaining C.
Stroustrup is not one of these. I recall the first time I read his book, back twenty years ago or so. I found it entirely unreadable, with so many exceptions added to the rule that you barely could remember either. There seemed to be no logic in the concepts, everything was very haphazard and unplanned.
Now, with twenty years of experience, a lot of programming languages in the back of my mind, I set out on a voyage of rediscovery, trying to impress myself with a book that I found cryptic and that I now would find insightful and revealing.
Not so. I read all of it for a second time, end to end, marking relevant sentences and trying to absorb the flow. There is none to speak of. The book is still cryptic. Only that now I know there are languages that are better designed, better executed and surely better described.
What made learning C++ so difficult, the astonishing number of rules and exceptions, is in hindsight poor design. Stroustrup tried to squeeze as many options into his language as possible, making C++ look and feel as bastardized as Perl would look after its 5th release.
The compiler tries to be smart, and does a lot of translation implicitly. Of course, this causes all sorts of weird errors, since it may become smarter than the programmer. To obviate, C++ allows you to override behaviors.
In general, C++ sounds like a language written at a time people still thought of memory as a precious commodity, while they were still not sure what they needed of the constructs provided by object orientation.
Take templates, for instance. Hard to tell what they are good for, if not to define collections and default operator behavior. But both cases would have been better served by a different approach, in which collections and operators are handled differently by the compiler, as native language types instead of as constructs.But aside from criticism to the language, the book itself is not well written. There is no general introduction to a concept, just an astonishing amount of rules that are listed in monotonous sequence, barely distinguished by their importance to the programmer. It somehow feels as if Stroustrup considers all rules children of his, and he doesn’t want to favor one over the other.
The book, again, suffers from a lack of structure. Headings, highlights, emphasis are not well distributed, adding to the overall impression of an amorphous entity that becomes inextricable.
C++, as it emerges from this book, is a language for the initiated that has no desire to use any different tool. It is the Perl of the eighties, the language that everyone mucks with, but that very few actually understand.
If you have ever worked in a larger engineering group that uses C++, you’ll have seen those frustrated emails come about, in which a poor chap asks why this piece of code doesn’t work, and there is always some guru that (in the most arrogant tone so typical of the Initiated in the Arcane) tell you about some rule that is on the footnote of a page in the Stroustrup.
It is no surprise that languages with more explicit approaches, like Java and C# are moving on and winning converts all over. C++ seems, in hindsight, a really bad idea.