Programming Books, part 4: The C Programming Language

It’s 32 years old, and it remains the single greatest book ever written about a programming language.  Its crown is secure; even if you’d not already read the title of this article, you’d know what book I’m talking about.  It’s the only language-specific book in Top Five programming books of the Programming Reddit’s FAQ.  Co-written by Reinvigorated Programmer regular Brian W. Kernighan and Dennis M. Ritchie, it’s not just the definitive book about the language in question, it’s the book the rewrote the book on what it means to be definitive.  Step forward, please, The C Programming Language! [amazon.com, amazon.co.uk]

The biography of the Beatles at allmusic.com has a very astute and resonant bit of analysis right in the first paragraph, saying that “they were among the few artists of any discipline that were simultaneously the best at what they did and the most popular at what they did.”  You could say the same for K&R, as it’s affectionately known: everyone knows it’s the best book on C, and (for once) the thing that everyone knows is actually true.

So what makes it so great?

Short, comprehensive, dense

First: it’s so short.  At 272 pages (this is for the second edition, published in 1988 and describing ANSI C), it’s shorter that Harry Potter and the Prisoner of Azkaban (317 pages) and little more than one third the length of Order of the Phoenix.

Second, it’s so comprehensive.  There is, essentially, nothing to be known about C beyond what is in this book.  If you can read those 272 pages, and understand them all, then you are well on the way to being a C wizard.  (Er, assuming you have the patience to go on to accumulate a decade of experience leading to wisdom, taste, good judgement and technical intuition.)

Third, and this is really a consequence of the first two, it’s so dense.  This is not a book that wastes words.  There are no extended introductory sections on Why You Should Learn C and C’s Place In The World.  The two prefaces (for 1st and 2nd editions) are one and a bit pages each.  The introduction is four pages.  Then we’re straight into Chapter 1. A Tutorial Introduction, which is 30 pages long and in that space covers:

• 1.1 Getting Started
• 1.2 Variables and Arithmetic Expressions
• 1.3 The For Statement
• 1.4 Symbolic Constants
• 1.5 Character Input and Output
• 1.6 Arrays
• 1.7 Functions
• 1.8 Arguments — Call by Value
• 1.9 Character Arrays
• 1.10 External Variables and Scope

At the end of that chapter, on page 34, is a sequence of five exercises, culminating in this one (and enjoy the characteristic Kernighanian understatement in the final sentence):

Exercise 1-24. Write a program to check a C program for rudimentary syntax errors like unbalanced parentheses, brackets and braces.  Don’t forget about quotes, both single and double, escape sequences, and comments.  (This program is hard if you do it in full generality.)

And, as tough as that may seem after only 30 pages, they really have given you all the tools you need to do the exercise by this point.

Say what you mean, simply and directly

Apologies if you’re getting bored of reading this Kernighan-and-Plauger epigram every time you return to this blog, but I really don’t think it can be over-emphasised.  Although this advice’s appearance in The Elements of Programming Style is of course in the context of writing programs, Kernighan also follows his own advice when it comes to writing prose.  No words are wasted; neither is your time.  Yet somehow the book avoids feeling rushed despite packing so much into so little space.

After the tutorial introduction, the remaining chapters cover:

• Chapter 2.  Types, Operators, and Expressions
• Chapter 3.  Control Flow
• Chapter 4.  Functions and Program Structure
• Chapter 5.  Pointers and Arrays [this, by the way, on page 93]
• Chapter 6.  Structures
• Chapter 7.  Input and Output
• Chapter 8.  The UNIX System Interface

That’s it for the chapters.  So they’ve got you doing systems programming by page 169; from page 185 to the end of the chapter, they show you how to implement malloc().  These guys are not messing about.

And then it’s on to the appendices, which rival those of The Return of the King for comprehensiveness (though thankfully without the notes on the differences between Eldar and Númenorean calendars.)

• Appendix A.  Reference Manual [because all the chapters are tutorial]
• Appendix B.  Standard Library [yes, all of it, in 18 pages]
• Appendix C.  Summary of Changes [since the 1st edition]

And finally, there’s just time for a characteristically comprehensive index before the book comes to a close.

In praise of small

Kernighan and Ritchie’s much-quoted preface explains the philosophy behind the book’s characteristically dense structure:

We have tried to retain the brevity of the first edition.  C is not a big language, and it is not well served by a big book.  […]  Appendix A, the reference manual, is not the standard, but our attempt to convey the essentials of the standard in a smaller space.  […]  As we said in the preface to the first edition, C “wears well as one’s experience with it grows.”  With a decade more experience, we still feel that way.

And it’s true that the book is only able to be as short as it is because the language that it describes is as small as it is.  I have the second edition of Stroustrup’s The C++ Programming Language, which clearly models itself on K&R and is about as terse as such a book can be, but its 691 pages make it fully two and half times the size of the original.  This, mind you, is the second edition of Stroustrup, published in 1991 only three years after the K&R second edition, when C++ was still a relatively well under control.  (I have not dared look beyond the cover of the current, 3rd, edition, but I see from Amazon that it weighs in at 1040 pages, and I am not in the least surprised.)

There is much, much more that I could say about the smallness of C, but rather that go against everything I’ve just been saying by bloating this review up into a monster, I am going to save that for a separate article.

Do it yourself

It’s also characteristic of K&R that they have this statement on the copyright page:

This book was typeset (pic|tbl|eqn|troff -ms) in Times Roman and Courier by the authors, using an Autologic APS-5 phototypesetter and a DEC VAX 8550 running the 9th Edition of the UNIX(R) operating system.

That they did their own typesetting is not just a cute touch, but an insight on the completeness of their mastery of what they were doing, and the care they took over it.  The book is not what you would call beautiful to look at, but the typesetting is wholly functional, at one with the text rather than fighting against it.  (Also, this statement is a gentle indirect boast, as Kernighan wrote the pic program and co-wrote eqn with Lorinda Cherry.)

(Kernighan, left, railing against innumeracy; Ritchie, right, auditioning for the role of Saruman.)

If I could analyse it, I’d do it myself

Finally, we come to the aspect of The C Programming Language that is hardest to explain — and hardest to do.

The bottom line here is that writing is an art.  You can hack your way through to producing tolerable text without being an artist, just as an uninspired programmer can bash his way through to wiring together an uninspired web application.   But just as it takes a Ken Thompson to invent and write UNIX, and a Dennis Ritchie to invent C and write the initial compiler, so it takes a Brian Kernighan to write The C Programming Language.

(Kernighan, by the way, is consistently very clear that he had no part in the birth of C, a common misapprehension due to his co-authorship of the book; but reading between the lines, it seems that he was very much the main writer of K&R.)

If all it took to write a truly great technical book was to write down everything there is to say about a subject and then ruthlessly distill it to its essence, then great technical books would be much less rare than they are.  That, I think, is a prerequsite; but it’s Necessary But Not Sufficient.  There is a graceful quality about the writing in K&R, even when it is brutally technical; it draws you on and in; it’s just pleasant to read.  It is, on occasion, gently humorous, though certainly not written for laughs the way that, say, Programming Perl is.  It’s exhilarating how the book takes you somewhere worth getting to, and does it so quickly.  It treats you like a grown-up; it is not “For Dummies”, but its intelligent approach is not the elitist kind that seems to want to make the reader feel inferior, but a warm intelligence that lifts you up to its level.  In short, it’s a book that wants to make you a better programmer.

The best way I can express it is to say that at the end of each section and subsection, you want to read on and find out what’s next.  That stands in stark contrast to too many other technical books, where I find myself peeking ahead to find out how much more of the current chapter there is to plough through before I can stop reading.

I wish I knew how they did it.  But I’m glad that they did.  Kernighan and Ritchie, we salute you!

Update (later the same day)

Nice dicussion on Hacker News, and some comments on Reddit.  As always there are dissenting opinions, but it’s been interesting to see the strong consensus that K&R really is the classic that I see it as.

(I add these updates with links to other discussions partly for my own benefit, to make it easier to track down what’s being said elsewhere.  Are they useful to others, too, or should I just keep the links in private notes rather than appending them to articles?)