Saturday, July 16, 2005

Day 74

[reading: Scott Meyers, "Effective C++ (3rd edn.)"]

I'm reading "Effective C++" again, with the publication of a new edition, and I'm struck by an observation. It's startling how much of the advice in early parts of the book boils down to: Understand how the compiler works. (Items 2, 4, 5, 7, 9, 10, 16 and 17 out of 18 so far)

This is an approach that I've got a lot of sympathy with; I really got to grips with Microsoft Word when I stopped observing the phenomonology of its peculiar behaviour, and instead sat down for half an hour to think about how it might be implemented internally. After that (even though I'm sure I didn't even get close to the true internals), I could cope with and predict the vagaries of the program much more effectively.

However, it does seem to me that one of the points of higher-level computer languages is so that programmers don't have to understand the details of the implementation. I guess if you just memorize the Effective C++ items and forget their explanations, then you can achieve that blissful state of ignorance—but it's safer and better to know the why and the how, which is why Scott's books sell so well.

But this does lead back to my underlying concern: that C++ is too complicated for mere mortal programmers. All of the individual features are there for a good reason, but taken as a whole the language is too big. A top-flight C++ programmer pretty much needs to know the whole of:

That's 1884 pages in total. Even Common Lisp: The Language only weighs in at 971 pages.

I just about trust myself to write C++, but that's only because I know I'll avoid the parts of C++ that I don't understand fully. I've only ever met half a dozen people that I'd completely trust to write C++ (one of them being Scott), which makes for a hard time supporting C++ code.