To give a concrete example; i had some experience in network programming/protocol implementations before i came across this book. In the "Notations" chapter, they show network message pack/unpack routines written in the style of printf/scanf functions with format strings specifying the packet layout! This was a eye-opening lesson for me in the use of proper notations and little languages. There is also some code snippet examples showing ideas behind Virtual Machines, Code Threading, JIT compilation etc.

Folks should also get Kernighan and Pike's older book "The Unix Programming Environment" to go with this. The chapter "Program Development" gives a complete example of developing a compiler for a small calculator language using compiler development tools (and no theory!) in around 50 pages. This is the smallest and simplest exposition that i know of on how to write a compiler.

In summary; get all of Kernighan's books and study them! :-)

* 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).

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

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.

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.

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

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

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.

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.

"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 startups, _ _ _.

fill in the blanks.

suggestions:

disrupting

changing the world

more efficient

productivity

cost savings

people savings

hardware unsavings

...

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.

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.

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.

A perfect example: Just about 3-4mins into the interview he said that the motivation behind the book was "kind of pretentious".

To me, and many others, his opinions on programming are amongst the most interesting and useful. In large parts because he can convey them so clearly.

Brian Kernighan prob couldn’t pass a leetcode hard interview in this ridiculous new world

I think I would actually enjoy an interview like that.

Yes, that's a really good one. I own a copy of it, bought years ago, and have read it pretty much cover to cover. Have also applied the guidelines in it, some.

for example, one of them is about a team that speeded up the run time of a quicksort implementation on a supercomputer by a factor of a thousand times (yes, times, IIRC, not percent), by doing successive optimisations at many layers of the stack, from high level algorithms and data structures, down to the hardware.

Algorithms and Data Structures always go together (like Yin/Yang) and hence i did not spell that out. At the time the book was written Structured Programming techniques and control structures were somewhat new and people wondered whether it was possible to really write efficient programs using these in a high-level language. In the preface/introduction itself Bentley points this out and says he is looking at efficiency at the "Design Level"(various) and thus you have chapters like "Modifying Data Structures" (Time vs. Space) and "Modifying Code" (mainly Loop rules) which show one how to transform code in the same language to a better form (we know this today as helping the compiler generate better object code). As he points out in the book; people forget the constant factors in big-oh and much efficiency can be had by tweaking this.

This is particularly true nowadays since there are so many interpreted/vm-based/jit-compiled/scripting languages where with some "under the hood" knowledge you can get good performance just by source level transformations.

You should try to get Rob Pike on. He'd probably make it a point to correct your pronunciation. I can hear him now...

We'd love to get Rob Pike on too! Currently working on it, although he's a little harder to get a hold of.

Thanks for sharing, OP.

He’s not the only author we’ve gotten on the podcast! We’ve already published our episode with Mark Richards on “Fundamentals of Software Architecture” but we also have in the can and ready to go over the next few weeks Neal Ford of “Fundamentals of Software Architecture” and John Ousterhout of “A Philosophy of Software Design.” That’s not public knowledge yet, so consider it an exclusive Hacker News comment section scoop, haha!

We also have some pretty big names we’re in talks with, but I won’t make any promises until the interviews are actually recorded. But we’ve been so thrilled at the author response so far and are super excited about the future of the podcast!

It’s definitely a breadth over depth kind of podcast, but I don’t think that’s necessarily a bad thing. We wanted it to feel like hearing two coworkers discuss a book over lunch. We don’t provide comprehensive reviews, but rather just highlight what we found the most interesting, while trying to keep it substantive.

I added "The Bit Player" (Claude Shannon documentary from 2018) to my watch list as well as "Recoding America," "Chip War," and "Endurance: Shackleton's Incredible Voyage" to my reading list.

Edit: This video humorously discusses the "leakage" I think of as bad: https://www.youtube.com/watch?v=M2PYgjgDdWg

I own a copy of that book and think it is good.

Kernighan and Plaugher had written "Software Tools" in RATFOR. Then they wrote "Software Tools in Pascal". And then, in direct response to the experience of writing that, Kernighan wrote a paper titled "Why Pascal Is Not My Favorite Programming Language". (Because writing in Pascal should have been way easier than writing in RATFOR, and it wasn't, and Kernighan gave some thought to why it wasn't.)

It's still an interesting read. You can find it online, for example at https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...

Note well: This refers to the original standard version of the language. Extensions like Turbo Pascal fixed many of the problems. (Except that, as he said, there was no portability between the extensions. Even that kind of was fixed by Turbo Pascal becoming the "standard" extensions.)

>You might get more than you bargained for on that topic

However, I did know about the points in your comment, mostly. [1]

That's because I happened to have read about the Tools book being first written in RATFOR (which, IIRC, stood for RATional FORtran) and then in Pascal, many years ago. I was a heavy Turbo Pascal user first, before becoming a heavy C and Unix user. And I used to keep reading the news about these subjects I was interested in. That's how I know about that topic.

[1] I said "mostly" above, because I somehow, wrongly, remembered that paper as having been written by Rob Pike, instead of by Brian Kernighan.

Both good books, and both were co-authored by Kernighan. I think they complement each other well.

It has a list of rules of thumb at the end, which contains my favourite part of the book. Pretty much all of them are timeless, but right in the middle is "Avoid the FORTRAN arithmetic if."

The one big thing I disagree with it on is the weird idea that you should never have 2 IFs in a row.

Do all four: modern / classic x proven / unproven.

Choose based on your gut feel plus logic plus reader suggestions.

Why live by constraints? ;)