I remember back in the 1980s paying something like £40 for a copy of Kernighan and Ritchie’s original book on “The C Programming Language”. An outrageous amount for a book which was a little over 200 pages, I thought.
However, during the 1990s, something happened to books about computer programming. Like the fast food junkies of our nations, they started to get bigger and bigger, with the essential meat surrounded by more and more extraneous fat. These days, most computer books are Doorstop Books. They’re at least 4cm thick, and make a great tool for propping open a door or killing a cockroach. As a tool for learning a programming language, however, I find them not so good. I’ve come to value conciseness in technical literature. I have things to do, and a bloated book too often stands between me and my task.
I’m sure there are people who work better with something like The Complete Book of C Programming, a mammoth tome with more than 1000 pages. But K&R is still out there getting rave reviews, gently updated for ANSI C, and a quarter of the length — because when you get right down to it, ANSI C just isn’t that complicated of a language. (And for the bits that are that complicated, you need the actual standard.)
Bloat is even more apparent if you look at books on UML. When you come right down to it, UML is just a bunch of conventions for how to draw diagrams that represent how pieces of software behave (or should behave) — glorified flowcharts. UML does not require 984 pages to explain. If you’re a programmer, you can get at least 90% of what you need to know about UML from Fowler’s UML Distilled, a mere 208 pages.
O’Reilly’s publishing genius has been that they generally find a happy medium between conciseness and bloat. They publish tech books which are concise enough to be useful, but large enough to look reassuringly definitive. Some of their books are excellent, and very few of them are truly bad. However, their …in a Nutshell series has started to show worrying signs of drift, with Java in a Nutshell becoming bloated with discussions of frameworks and reproductions of the API documentation, rather than sticking to its subject matter.
Make no mistake, though, this is a book for software engineers. The chapter on functions was heavy going, doubtless because I haven’t done any real functional programming in years. I found myself re-reading sections multiple times, as the squirrel of recollection scurried around in the dusty attic of my memory.
In fact, I’d love to see the obvious next step: DOM: The Good Parts, a book which describes only the standard parts of the DOM, and then flags the bits that don’t work on common browsers.
And then perhaps someone who likes a real challenge can attempt to write C++: The Good Parts — with Appendices A thru E being the bad parts, the awful parts, the abysmal parts, the parts even worse than that, and the parts that make you wonder what Stroustrup was smoking.