Hacker News Reader

Hacker News

Comment by kaycebasques | Hacker News Reader

Parent Full thread

kaycebasques

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

View on HN

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?

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.

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

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

...

Reply on news.ycombinator.com