Hacker News Reader

Just ordered the true Gang of Four:

* The C Programming Language

* The UNIX Programming Environment

* The Practice of Programming

* The Elements of Programming Style

I've read the C book before and also remember the writing to be excellent. I'm sure I'll pick up lots of programming wisdom but I'm also approaching this as a technical writer, figuring out what exactly makes Kernighan's books so good. I have a hunch that Kernighan has studied writing a lot, or has at least done a lot of "first principles thinking" about writing. The title "The Elements of Programming Style" for example is a reference to one of the most famous books about writing style, "The Elements of Style" by Strunk and White (which everyone should read once; it literally fits easily into your back pocket).

To your first three above, add Marc Rochkind's Advanced Unix Programming and Richard Stevens' Advanced Programming in the Unix Environment and you have got yourself a complete course in C/Unix programming which is the bedrock for everything else; C is the "lingua franca" and Unix (via its variants) the "standard" OS.

Tip: Many of these old books can be had for cheap as used copies on Amazon/Betterworldbooks etc.

>you have got yourself a complete course in C/Unix programming which is the bedrock for everything else; C is the "lingua franca" and Unix (via its variants) the "standard" OS.

Somewhat over the top comment.

I may be an even stronger proponent of C and Unix than you, partly because I grew up on them, and partly because I like them, although they have their share of issues.

Still, calling them the bedrock and standard is too much. There are other alternatives. Until Android and IOS based systems boomed, Windows outnumbered Unix and Linux systems by a huge factor, which I cannot even estimate.

> Somewhat over the top comment. ... Still, calling them the bedrock and standard is too much.

Nope, i meant exactly what i said. The point is not popularity/commodity but understanding a domain from the foundations.

I am one of the oldies who started with (in chronological order) MS-DOS, a brief foray into Mainframe COBOL, 16-bit Windows (Windows 3.1) to 32-bit Windows (Windows NT 3.51 & 4), then to Solaris/Linux and all using C/C++. So i had actually programmed in Windows before Unix. There was only Dave Cutler's book on the Windows NT kernel then with everything else being only on programming the GUI subsystem (Charles Petzold and Jeffrey Richter were the notable ones) whereas in the Unix world you had Maurice Bach/Marshall Mckusick/etc. books explaining the kernel and Marc Rochkind/Richard Stevens/etc. explaining how to program it. I still remember reading the 1st edition of Rochkind's book (there were only around a dozen system calls then and the book was less than 200 pages i think) and understanding everything (Unix was a simple monolith then) while Windows was made up of a kernel+various subsystems and it was rather hard to understand what was what. And through it all C was the common "glue" lingua franca which allowed one to program all of them.

The above situation persists to this day in spite of the explosion of languages/OS/Architectures. A knowledge of C/Unix will allow you to understand and program any system be it bare-metal/kernel-level/app-level/system utilities. You may not need it at your job but a knowledge of C/Unix (you don't have to become an expert) will give you a solid bedrock to hang your higher level understanding on. It will also make your transition to other languages/OSes easier since you will have a good understanding of what is going on underneath.

Corrigendum: Consulting Rochkind's 2nd edition of AUP book it says; the 1st edition included about 70 system calls while the 2nd edition includes about 300 gleaned from SUS (https://en.wikipedia.org/wiki/Single_UNIX_Specification).

the first paragraph of your comment is in contradiction to the third.

so, i am not interested in discussing things further.

> the first paragraph of your comment is in contradiction to the third.

No.

I am not interested in explaining obvious facts either.

I bought the Stevens’ book sometime in the 90’s. I believe I still have it, but I haven’t opened it up in years or maybe even decades at this point, so my recollections might be a bit off.

The book predates important developments like epoll/kqueue, so is it really a good recommendation today? Are there more modern alternatives?

There is a 3rd edition of Steven's APUE published in 2013 but i am not sure whether it covers epoll/kqueue specifically (i don't have this edition). Most probably not since these are specific to Linux/BSD. Stevens/Rochkind only cover the base Unix apis for I/O multiplexing/Asynchronous I/O (select/poll/signals/aio apis) gleaned from SUS (See https://en.wikipedia.org/wiki/Single_UNIX_Specification). You would be better off consulting the specific documentation for these system calls in its OS reference and the various articles describing/comparing them online.

For a Linux specific alternative Michael Kerrisk's The Linux Programming Interface seems pretty good.

If we're going all in on the unix lore here, I'd suggest kernnighghan's book "Unix: A Memoir" as an optional add-on. Lots of good lore and history as to "how and why" things work in such a such way. Some commands in there you may not use or maybe heard of but not fully understand, such as grep, why the word grep, why the other types of grep such as egrep. And on the topic of grep, clearly a very popular command early on, so you also get a sense of "what were seen as the core commands commonly used initially" (and whether those may be useful to you today)

No idea what your background is, but since you just bought four books, make sure you're spending more time reading and writing code than reading books. Some people fall into the theory trap and don't spend enough time making use of that theory.

Agreed. Reading books is great if it's replacing Twitter and Reddit time. It's not great if it's replacing coding time.

> I'm also approaching this as a technical writer, figuring out what exactly makes Kernighan's books so good.

I am docs lead for https://pigweed.dev

I will probably also eventually post my findings to https://technicalwriting.dev

One of the great things about The Practice of Programming is how much it references other non-coding works. You can tell Kernighan draws his knowledge from many sources, not just technical ones.

Well one does wonder, where did the icons like BK pick up their own craft? Surely there were no programming books before computers. Which shoulders did our giants stand on?

> where did the icons like BK pick up their own craft?

They invented it and that is also why they are able to express their ideas so clearly. Small groups of smart people at various institutes/companies coming up with ideas, bouncing it off of each other, learning from each other and settling on the essence.

The mathematician Abel is supposed to have said; "It appears to me that if one wishes to make progress in mathematics, one should study the masters and not the pupils." This is true of all domains.

Brilliant question. Never thought of it before, but it make a lot of sense.

Math(s) background is one guess I can make. Based on the fact that many of those pioneers had a basic degree in math and then pivoted (heh) into computer science. In fact some of them started before computer science was even a formal thing.

In fact if you disregard the contents and preface, the very first words in The Elements of Programming Style are a quote from The Elements of Style,

"It is an old observation that the best writers sometimes disregard the rules of rhetoric. When they do so, however, the reader will usually find in the sentence some compensating merit, attained at the cost of the violation. Unless he is certain of doing as well, he will probably do best to follow the rules."

William Strunk and E. B. White, The Elements of Style

in poetry, it is called poetic licence.

in startups, _ _ _.

fill in the blanks.

suggestions:

disrupting

changing the world

more efficient

productivity

cost savings

people savings

hardware unsavings

...

> This is the smallest and simplest exposition that i know of on how to write a compiler.

I haven't read Kernighan and Pike's book but another really small compiler exposition I like is Wirth's PL/0 in "Algorithms + Data Structures = Programs". A little outdated at this point, but still a very pleasant read.

Thanks for the pointer, will take a look at it. I don't believe these things become "outdated" unless you are a bleeding edge practitioner. For most of us "ordinary" Programmers what is needed is breadth over depth and a general idea of what the subject is about so that we are not entirely clueless. Depth will always come when we actually get to work on a project which needs that specific expertise.

Can only second you. His style is by far my most favorite among all other technical authors. And thanks for the reminder, time to get another one of his books.

> His style is by far my most favorite among all other technical authors.

All authors should learn from Kernighan's books (co-authored with Plaugher/Ritchie/Pike) on how to write technical books. 90% of all the computer programming books published nowadays are too verbose (why the hell are they so huge?), meandering over inessentials, lack of clarity in language, a paucity of clear and precise examples and overall just a waste of paper. Reading them is more of a chore then enlightening whereas all of Kernighan's books are only a little over 200 pages, dense with knowledge and a pleasure to read.

In discussions with colleagues they blamed the absurd demands of the publishers in terms of hitting specific volumes (in pages), which oddly reminds some past relationships I had with management and sales departments as a developer.

As someone who has been programming professionally for 10 years - what would I gain from reading this book? Not to sound snarky but genuinely wondering what makes it a 'must read' for people who are comfortably coasting in their careers

Not being rude but 10 years of experience is dependent on what that experience actually entailed. IIRC Steve McConnell in his book "Code Complete" says "You can have 20 years of experience or 1 year's experience repeated 20 times". The inference should be clear.

I have been programming since the early 90's and can assure you there is more knowledge in these sort of books from certain authors than most of the books being published today.

The book brings together a lot of aspects to Programming some of which may seem obvious but still have nuances to think about. It also teaches you advanced ways to think about your design (eg. the "Notations" chapter i mention in another comment) where you make your code simpler and elegant by inventing simple DSLs/VMs for parts of your problem. It is this "holistic" view of programming that i think is so essential to understand.

If you're at Goog or Meta, you probably have seen best practices around you. If you're working at elsewhere, some things in the book would might be new to you.

Thanks for the heads up on "The Unix Programming Environment!" I've been searching for a book with a concise explanation on how to write a compiler, and you can't go wrong with one from Kernighan!