32 years on, K&R's "The C Programming Language" still stands alone | Hacker News Reader

32 years on, K&R's "The C Programming Language" still stands alone

reprog.wordpress.com

142 pointsMikeTaylor66 comments

I think it says something that K&R C, as a book, is significantly more readable and concise than most programming books nowadays. Part of it is the language, but part of it is simply how the book is approached. Simple statement, simple example, move on.

I mean, compare that book to the other programming books on your shelf. It is positively minuscule. And if you compare the writing to that in a more modern programming book, there's certainly a lot of wasted text in newer books.

My latest programming book is The Essential ActionScript 3.0 by O'Reilly, and there's way too much embellishment in the text. Not only does it make it longer to read, but it also makes it harder to find particular information, and quickly absorb it.

I learned C almost exclusively from K&R C, and I know many others did too, and to this day I wonder how it is that all these new programming language books can be such monolithic texts.

"Essential", they say.

I found Doug Crockford's "Javascript: The Good Parts" to have the same qualities as K&R's C book. Concise, readable and dense, a 'must read' for aspiring Javascript programmers.

The thing that has always struck me about K&R is that it contains no fluff. You get so much information for each paragraph, that you often have to re-read them to get all the information contained therein. Probably the programming book I've used the most.

In contrast, the C++ programming language is a mouthful, and ended up being just another pretty book on my bookshelf.

Stroustrop is, or at least in its later editions became, a pretty indespensable C++ book. Most of the topics in C++ are best addressed by it. Unfortunately, C++ is a nightmare of a language, so there are many, many topics, and you don't read it cover-to-cover any more than a cook would read New Pro Chef or McGee cover-to-cover.

The copy of Stroustrop's book I have has all of the program text in a proportional, italic font. It was murder on the eyes.

The growth from the first edition (skinnier than K&R as I recall) to the third astonished me.

I donated mine copy of Stroustrop to one of my classmate with whom I was not having good terms.

I have read neither K&R nor the C++ book cover-to-cover, but the C++ book is standing practically unused on my bookshelf, while my K&R is noticeably worn.

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.

Say what? This is like saying that once you know what all the commands in Illustrator do, you're well on your way to being a professional illustrator. The reason that K&R is so small is that so much of C programming happens outside/above the language.

I like K&R a lot, and I won't argue that it's the best soup-to-nuts C book (though I recommend C Interfaces and Implementations more heartily). But if everything you need to know about C is in K&R, how do you implement a balanced tree?

(I caught myself typing "how do you implement a hash table", and remembered that K&R actually has a hash table in it. Damn you, K&R!)

@tptacek and others on this thread, what books do you suggest to learn modern C programing? I am an experienced programmer, but all of my experience has been with JVM languages. I would like to be able to read and debug C/C++ programs - so which books provide a good start on idioms, libraries and tools?

_C Interfaces and Implementations_ by David Hanson.

I'm using it as the textbook for a weekend C class I'm about to run for a bunch of Ruby/Java programmers, because CII basically gives you back all the data structures you have in Ruby that C "takes away" from you.

It'll also teach you a style of C development (ADT-centric, modular, heavy on function pointers) that holds up pretty well and is relatively modern.

Reading that at the moment to improve my C style. It's excellent.

This looks like tptacek's review on Amazon:

http://www.amazon.com/review/RMXKDJNH8UOPU/ref=cm_cr_rdp_per...

It's not exactly a book suggestion, but hacking on the Linux kernel can give you experience with a sizable code base in reasonably good C. If you are or want to be a Unix developer at all, become good friends with the man command and make sure you have the complete set of manual pages installed (and, ideally, the POSIX original man pages as well to compare your system to the spec).

tptacek, I LOLled at your last comment :-)

But I think you're being unfairly selective in your quoting of the original article. _Immediately_ after the part you excerpted, it continues: "(Er, assuming you have the patience to go on to accumulate a decade of experience leading to wisdom, taste, good judgement and technical intuition.)"

But if everything you need to know about C is in K&R, how do you implement a balanced tree?

Read a good algorithms text to learn about balanced trees. Once you understand what one is, you ought to have learned enough about C from K&R to be able to implement one in C.

Java programmers don't need to read algorithms books to get sorted-access lookup tables. That's all I'm saying.

And software managers don't need to know anything to tell you to write a program - I wouldn't brag about knowing Java here in 'C' land ;-)

Being a C wizard doesn't mean you know how to implement a balanced tree. It means that if you understand a concept, like a red-black tree for example, then you can efficiently implement it in C.

It was written in a different era where publishers weren't inflating page counts for sales.

If only said publishers understood how much we value succinctness...

It doesn't hurt that the total number of constructs in K&R C is really quite small. I'm not sure there are any current languages with comparably few constructs; maybe Arc. Even Scheme is bigger, at least for a recent version (say, R6RS).

True, but the revolt against R6RS has been ... fierce. None of the new steering committee members was in favor of it and we expect a move back towards the old virtues.

Still, Scheme does try to address a lot of higher level things, e.g. the full numeric tower, whereas C shines as a universal very close to the metal assembler.

Even with that, look at the books on C programming in stores (there still are a few). All of them are at least double the size of the K&R book.

Of all the C++ books, there was a C++ in 10 minutes from SAMS that was small, dense packed, and informative. It was really weird coming from them.

The first and probably only programming book I've read completely.

"Learning Perl" was the first one I read all the way through. I read most of K&R, it was a similar experience, many years after reading the Perl book.

How does it compare to C Programming: A Modern Approach, by K.N. King? That was great for learning C. Very readable.

Really, downmodded for politely asking an honest question?

Had anyone used both? Will I get downmodded for asking another question?

Kneejerk downmodding has become somewhat epidemic recently (in the last few months?). Most of the time more thoughtful users tends to correct this problem later on, though.

It probably helps that downvoting is only possible for newer posts (at least from my perspective), while upvoting is always possible.

I usually compare on what I think a comment is worth and what it has at the moment, and then vote to make the `is' closer to the `should'. At least for upvotes. In generally I only downvote stuff that lowers the quality of discussion.

It would be interesting if we had a voting system, that worked a bit like eBay's `bidding agents'. I.e. a system where you vote by setting a target score, and the system casts an up- and downvote as necessary. Of course we would need those base-votes to be recastable (but only automatically).

The current system is a special case of this, where the target score is either plus infinity or minus infinity, and you can't change the target score once set.

P.S. Please forgive my off-topic ranting in this discussion about K&R.

It was used for my programming class, however the professor recommends K.R for experienced students who are new to C.

I personally find Steele's C: A Reference Manual far more useful in day to day hacking.

But, that's one of four Steele-authored language specs I look at frequently (Common LISP, Scheme, and Fortress), so I might just have carefully tuned my search methods to his writing style.

But Steele isn't much thicker. It's not hard to see that he was sticking to the K&R philosophy .

Not really, unless page count is your only metric. If you've read any of Steele's other language definition books (I've read all of the first Common Lisp one and some of the Java 3rd edition), you'll see it's clearly in the same style as the others. Also not entirely like the Scheme Revised Reports, which really set the standard for conciseness ^_^.

i never realised that was the same guy steele! (to be fair, it's harbison and steele, so he's second author and it's not clear how much was his work).

i've mentioned preferring this book over k&r here before, but as someone pointed out they do slightly different things - k&r is more about teaching how to use c.

but apart from all that, how come you get to use fortress frequently? what are you doing? is it becoming more popular? has it survived oracle?

I found K&R great ... until I got to the arrays and pointers chapter. It wasn't my inability to get the concept, I think, the Lions' Commentary n UNIX 6th Edition, with Source Code which I tried next did the trick.

And nowadays I too keep Harbison and Steele handy, I lost track of my copy of K&R sometime in the '80s.

This is one of the few books I've kept on my bookshelf for many years and still read through it every so often for a C syntax refresher. It's a great read since C syntax and conventions are still so pervasive in many of today's languages. Perhaps, it is one of the few programming books that can be passed down from one generation to the next.

K&R is overrated, just like many "cult" books are. I read C: ARM by Harbison and Steele and after trying to read K&R I stopped because I wasn't getting anything new out of it.

Edit: Further proof of this is the blind downvoting typical of critiques of "cult" books. K&R just happened to be there at the right time and it was the first programming book for many people. Their nostalgia makes them think that it is a very good book, when in fact is a simple book that describes a simple language. Nothing bad about that, but nothing spectacular either.

"a simple book that describes a simple language" -- this, and this alone is worth all the praise it gets. It's one of the best books I've read as far as getting out of your way and letting you learn the language. No silliness, no wasted space. It is a super efficient book that gives you everything you need to get started.

I'm glad the other book worked for you though!

They're different books for somewhat different purposes. Harbison and Steele was written because Tartan Labs (CMU (compiler gods) spinoff) needed a strict definition of the language suitable to use for implementing it. And that's what Steele has done with all his language refs (well, I haven't looked at the Fortress one yet).

K&R ... I don't know. To really judge it, I'd want to e.g. look at the Algol 60 spec, and some inbetween.

Anyway, I'm not sure it's a "cult" book, but I do agree it's overrated (see my other comment; at the time I found the Lions' Commentary to be the better tutorial, but it had that tiny problem of being samizdat).

I'm reading it for the first time right now, and without nostalgia, at 100 pages in I'm very impressed.

Flip to the part about longjmp, and see if you still are.

It's not surprising that you wouldn't get anything new from K&R after finishing H&S. H&S is intended to be a reference manual whereas K&R is more of a tutorial (that doubles as a reference manual, especially before ANSI C was created). I think few people would attempt to learn C by reading H&S.

Personally I adore both books. I do find H&S more useful particularly because it is more comprehensive and up to date (very good coverage of C99, not just a listing of changes in some appendix but has discussions about C99 throughout the book).

That was my first programming book, and I learned not only C from it, but programming in general. It's been translated into many languages, I read it in Hungarian. Check out the various covers: http://cm.bell-labs.com/cm/cs/cbook/

K&R's C Programming Language is like the language: spare and elegant. It is not a beginner's book and does not coddle the reader. It is a book for programmers. And it reads as well today as it did 32 years ago.

Ah... this book brings back memories for me. This is the only programming book that I read till the end three times, not to mention the countless other times I use it for reference. The only book that can almost match this book is Effective Java Programming.

These are the only two books I bought _after_ reading them from front to back as they are a must have for my library.

This is one of the very few if not only tech books I cherish and would never let go of. I'm not a C guru, I did a lot of C in school, but since then almost none.

I've been wondering when or if I can get this on the iPad. Even though I own the hardcopy, it has seen better days and it's starting to lose it's binding.

The first post here could not have said it better:

http://www.reddit.com/r/programming/comments/bn8y5/kernighan...

K&R is not only about C. It is about programming practices in general and is content-packed. So much power in so thin book, just like C itself, a language with only 32 keywords.

"Ritchie, right, auditioning for the role of Saruman."

What the hell ;)

Very nice semantics, but hideous syntax. Pascal had it done right with a more linear declaration syntax. C looks like lisp in a bad way if you make slightly nontrivial declarations. Of course to make matters worse somebody went on and made C++, which must be the most hideous language ever to evolve, possibly because its creator borrowed heavily ideas from how his native natural language Danish was formed; It is mostly comprised of guttural sounds and every new groan you make is added to the language. It has been said that C++ is to C what lung cancer is to lung.

Basically we will never get rid of C, for there is just too much piled up on it. C++ though we should replace because it is an atrocity to programming.

C's syntax is much more terse than Pascal's; whether that makes it better or worse is open to discussion. begin...end or {...}? I would argue that Pascal's syntax is easier to learn, but that C's is easier to use once learned. And since I spend more time using languages than learning them, the latter is more important to me.

The nontrivial differences are more interesting. To make declarations look similar to use was a gigantic mistake.

http://cdecl.org/

How is it a mistake? In C, if you know how to use it, you know how to declare it, and if you know how to declare it, you know how to use it. I don't see how one can make even a remotely plausible case that doing it otherwise would be an improvement.

  char * (*(** foo[][8])())[]

  declare foo as array of array 8 of pointer to pointer to function returning pointer to array of pointer to char

Which do you prefer reading?

Why would you write code like this?

The point is not that, but that as soon as you make slightly nontrivial declarations it is not readable in one pass.

Well, the K&R book talk about the complicated declarations, and recommend the use of the typedef command. Also, it contains a simple program called "dcl", analogous to what you linked.

If that's what you consider "slightly nontrivial", I never want to see what you would consider a difficult type declaration.

I'd volunteer some Haskell, but I am afraid that while complex, it doesn't have enough line noise in the type declarations.

They're both equally illegible to my eyes!

The first, for a couple reasons, but that's not relevant. My point was that I see no advantage or even plausible case for having declaration syntax be different from use syntax.

If C made us declare foo using the second format you gave, we'd still have to write, e.g., ((foo[12][3])())[7] in the code where we are actually trying to use foo.

Can you look at a declaration in the second format, and compare to where the variable is used, and see quickly if the usage is correct? With the current declaration format, it's easy--because declaration and usage use the same format.

C's type syntax for functions, pointers and arrays is terrible; it was an experiment that failed. C++ made it worse when introducing references and cv-qualifiers.

In the 80's we used to say: "You can't compare Pascal to C. It's like comparing a bicycle with training wheels to a ten-speed racing cycle."

> to a ten-speed racing cycle.

Lacking brakes.

Reply on news.ycombinator.com