Brian Kernighan on “The Practice of Programming” [video](youtube.com)
youtube.com
Brian Kernighan on “The Practice of Programming” [video]
https://www.youtube.com/watch?v=_QQ7k5sn2-o
116 comments
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).
* 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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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
"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
...
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.
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.
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.
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!
I love the Practice of Programming. Of all the books on programming that I've read, the lessons of that book are the ones that remain strongest in my mind. I've not read it in many years but I feel it influences my practice everyday.
It was the first time I’ve ever read it and I was surprised how much of it still held true given it’s 25 years old. Some of the specific programming examples are pretty outdated, but the general ideas are as solid as ever!
Curious what examples you felt were outdated.
They mention at one point that Java doesn't have a way to pass a function as a parameter to another function. That was added in Java 8 with lambdas. That's just one off the top of my head.
Nit: it's still right. Lambdas are just functor sugar.
The only mainstream languages where you can actually pass function references around, without them being sugar for some complex object that the compiler creates are C, C++ and Rust. And it's not trivial to do in Rust.
Ah ok thanks.
Love Kernighan, such a humble person. In one of the videos that he was featured on in youtube, he spoke about how he was solving a difficult problem in his thesis which turned out to be NP-complete before the theory had been fleshed out. Emailed him for his thesis and got a pretty quick response, was a really interesting read.
It's a rare combination to find someone both as intelligent and humble as he is. Truly a blessing to our industry.
I believe you are right as intelligent grows, but the very top end usually has people excelling in many things and personality as well. At least that’s what I noticed.
Certainly successful intelligent people often excel in personalities. Hard to get places without playing nice with others to a degree.
> Love Kernighan, such a humble person.
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.
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.
see the publications section here for more of his books:
https://en.m.wikipedia.org/wiki/Brian_Kernighan
https://en.m.wikipedia.org/wiki/Brian_Kernighan
I wish interviewing now was more about knowing the concepts in that book versus leetcode
Brian Kernighan prob couldn’t pass a leetcode hard interview in this ridiculous new world
Brian Kernighan prob couldn’t pass a leetcode hard interview in this ridiculous new world
My last interview cycle I interviewed with some big names (Stripe, Square, Shopify, etc.) and was pleased that none of them asked any LeetCode style questions. All pretty practical programming stuff. Stripe had an interview where they had forked the Jackson Java library, introduced a bug, and then asked me to find and fix it. Pretty unique style, but much more applicable to the actual job of programming.
> Stripe had an interview where they had forked the Jackson Java library, introduced a bug, and then asked me to find and fix it.
I think I would actually enjoy an interview like that.
I think I would actually enjoy an interview like that.
[deleted]
In my most recent interviews with Apple and Amazon there were no LeetCode questions after the phone screen. Quite a change from previous experience.
What are they asking these days and what positions was this for (i.e. a senior role?)
For the Apple interviews it was all systems programming stuff, e.g. "implement mmove", "read integers off the wire preserving endianness", etc. Amazon was much more focused on behavioral stuff (i.e. their leadership principles) and system design.
This was for Amazon L6 and Apple equivalent, nothing very senior.
This was for Amazon L6 and Apple equivalent, nothing very senior.
Really? In my Amazon interview last month for a SWE position they asked a LeetCode style question after the initial phone screen about writing a social network data structure (a directed graph) and then asked me to write a method to traverse it to n-depth.
I did have an internal referral from an SPE so it's possible my experience wasn't typical.
That's a clever interview question, but wouldn't that suffer from diffing origin/main? Or was this a in person / on screen interview with no git history?
It was an on-screen virtual interview, so while I believe they had scrubbed the Git history, you weren't allowed to look it up.
I would say that I would hire that person if that was the solution. That said maybe repo wasn’t included in interview. (Would be even better if person figure out how to diff against a new clone)
Reminiscent of Peter Higgs (Nobel Prize winner for the eponymous boson) saying that he would not be able to get an academic job today, not to mention Katalin Karikó (Nobel Prize winner for mRNA) being demoted by UPenn for not attracting grant money.
Another author and his books in the same category of excellence as Kernighan and his books, is Jon Bentley and his books Programming Pearls and More Programming Pearls.
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Also his earlier slim Writing Efficient Programs book. What this teaches you is how to think about efficiency from the top down with an emphasis on Algorithm and Language and hence useful to all programmers. Pair it with modern books on efficiency which deal mainly with compiler-level/OS-level/Processor-level performance techniques by Agner Fog, Fedor Pikus etc. and you get a complete picture.
>Also his earlier slim Writing Efficient Programs book.
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.
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.
the war stories briefly mentioned in the footnotes of the book, are very interesting too.
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.
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.
>with an emphasis on Algorithm and Language
did you mean algorithms and data structures?
did you mean algorithms and data structures?
No.
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.
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.
Added to the backlog! As our audience grows, we've debated doing live backlog grooming on YouTube so that listeners have a chance to chime in and voice their opinions on what we should read.
I think that's a good idea.
The "g" is silent, folks.
You should try to get Rob Pike on. He'd probably make it a point to correct your pronunciation. I can hear him now...
You should try to get Rob Pike on. He'd probably make it a point to correct your pronunciation. I can hear him now...
Yeah, someone on YouTube pointed out the same thing. D'oh. I wish Brian would have corrected us!
We'd love to get Rob Pike on too! Currently working on it, although he's a little harder to get a hold of.
We'd love to get Rob Pike on too! Currently working on it, although he's a little harder to get a hold of.
I'm only one third of the way through the video, but could see that the podcasters are asking some good insightful questions.
Thanks for sharing, OP.
Thanks for sharing, OP.
I just found out we cracked the Top 20 on Hacker News! Crazy! I’m Carter, one of the podcasters from the video. I’m glad you’re enjoying it! It was such a huge honor to talk to Brian Kernighan.
I hadn't heard of this podcast until just now, but an entire show dedicated to software book sounds like a dream come true! I'm going to download a few of these for the train. I love that you guys are diving into such a niche!
Thanks so much! When we had this idea, I was certain that it had to have been done before because it seemed like such a gap in the market. To my surprise, it didn’t exist! We love the format because not only do we learn a ton, but by focusing on the books we keep the discussions substantive and avoid becoming the millionth “tech news of the week” podcast.
I found your podcast a few days ago on a different book. Keep it up, I think you have a good niche and doing something you rarely see, which are deep dives on programming books. The only other one I really know of is Connor Hoekstra has a couple nice playlists on SICP and something else but this is a little different, good job.
Thanks for listening! Which book was it that you found?
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.
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.
How did you get him on your podcast? That's amazing!
To be totally honest, I just looked up his Princeton email and asked lol. I told him we loved the book and would love to interview him about it. He was like “What? I haven’t thought about that book in 20 years. But I’m sure we could find something to talk about for an hour.” He was so amazingly kind and generous with his time.
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!
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!
Years ago he was a guest lecturer for a class I was taking from Scott Bradner - as you said, incredibly nice an approachable guy. I could have listened to him for another hour or two.
We would have loved nothing more than to talk to him for hours. He was already calling in from England while on his vacation, so I didn't want to take any more of his time, haha!
Authors seem to treat podcasts the way celebrities treat talk shows, it’s basically free marketing.
That's been my experience so far, especially because the focus of the podcast is explicitly on the book. It's not, "Hey, come on my podcast to discuss the latest AI development and then maybe plug your book at the end," it's "Hey, come on my podcast solely dedicated to discussing the book you've written." Authors seem pretty eager to participate in that.
gotcha, and agreed.
bwk is one of my software heroes, along with dmr, bs, lw, gvr, etc.
bwk is one of my software heroes, along with dmr, bs, lw, gvr, etc.
A nice value in this format (since it discusses books) would be to have a comment or portion of the description dedicated to listing the books (or ideally the media) discussed to a list.
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.
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.
What do you mean by this exactly? Like a list of all upcoming books we’ll discuss? If you’re curious, you can find that on our website at www.bookoverflow.io!
I think they mean that the description of the episode should have a list of books (and maybe other resources) that were mentioned in the episode itself.
This exactly, yes, thank you. Sorry for being vague.
Oh yeah, that’s a good idea. We’ll have to do that. We’ve been debating setting up Amazon affiliate links to the books in the episode descriptions. We were going to wait until we were a little bigger, but after today we might have to speed up those conversations, haha.
I can appreciate supporting the effort, but the "stickiness" of Amazon affiliate links seem pretty pernicious. I briefly tried to find a source for this and failed, but my understanding is that the affiliate can see any product purchased while the affiliation through the link is active, which is something like a 24 hour timeout or another link for a different affiliate is used. Maybe my perspective is out of date, if so my apologies, but that seems like a net negative contribution to personal privacy of viewers.
Edit: This video humorously discusses the "leakage" I think of as bad: https://www.youtube.com/watch?v=M2PYgjgDdWg
Edit: This video humorously discusses the "leakage" I think of as bad: https://www.youtube.com/watch?v=M2PYgjgDdWg
Yeah, definitely not my area of expertise. We’ll need to explore it further and make sure there’s nothing sketchy before making a decision.
You can always provide two versions of each link (affiliate/direct)
Good idea. Now that I think of it, I've seen other creators do something similar.
Sorry, I didn't mean upcoming books, just the media discussed in the episode. Like the ones I mentioned adding to my watch/reading lists. It would have made finding them a little easier is all and could serve as value to the description since it's certainly the case that they were discussed in the video! :)
I suggest you add Software Tools in Pascal to your list of books to podcast about. Also by Kernighan.
I own a copy of that book and think it is good.
I own a copy of that book and think it is good.
You might get more than you bargained for on that topic.
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.)
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.)
Just to add to the above; RATFOR (https://en.wikipedia.org/wiki/Ratfor) was implemented as a preprocessor to Fortran with its control structures almost identical to those of C. So going from the freedom of C syntax to the straitjacket of Pascal might have been too much and hence the Pascal paper.
Here is the pdf of Brian Kernighan's paper on RATFOR - http://www.econ.uiuc.edu/~roger/research/repro/ratfor.pdf
Here is the pdf of Brian Kernighan's paper on RATFOR - http://www.econ.uiuc.edu/~roger/research/repro/ratfor.pdf
Thanks for your comment.
>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.
>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.
[deleted]
Finding 'Software Tools in Pascal' in my local mall bookstore, before I even had access to a computer running Pascal, turned out to be a kind of cheat code for my career. I marveled at the ideas and the writing and it set me up to acquire much of the the rest of the Kernighan canon.
Kernighan is also a co-author of The Go Programming Language book, at least of the 1st edition.
Is that why Go forces K&R brackets instead of letting you choose?
Maybe you already know this and your comment was in jest, but the real reason is that the Go lexer automatically inserts semicolons (https://go.dev/doc/effective_go#semicolons) using heuristic rules which forces the opening brace to be on the same line.
I knew that it inserts semicolons but I still don't understand why they removed semicolons entirely and forced a bracketing style. The comment was in mild jest to that maybe being the reason why
I never liked
that decision.
sneer. sneer. sneer.
heck, that sounds like three cheers. so i should abbreviate it to three sneers in future. :)
so, three sneers, for yet another blindly downvoting hn hive mind bro type who can't handle even an innocuous opinion (like my "never liked that decision" comment above), just because it is different from their own opinion. in other words, homo intolerantis.
there are a lot of such jokers on this site.
who cares about that behaviour, though? not me, for sure. hn is just some site, not important in the real world, except for those people who have nothing better to do than hang around here all day or night, and snipe at and try to put down others. iow, trolls and loser types.
as amy hoy said somewhere a while ago, maybe on her site or on twitter, fuck hn.
look, uncle darwin, i discovered a new (creepy) subspecies of homo sapiens, who i hereby name homo intolerantis.
:)
keep downvoting me, bro type, even pull in your friends to do more of it, and thereby waste all your time, and get ulcers and high blood pressure because of my innocuous comment, probably you have a lot of free time because of no job because of layoffs, while i have a good laugh at your stupidity and cheap malice.
heck, that sounds like three cheers. so i should abbreviate it to three sneers in future. :)
so, three sneers, for yet another blindly downvoting hn hive mind bro type who can't handle even an innocuous opinion (like my "never liked that decision" comment above), just because it is different from their own opinion. in other words, homo intolerantis.
there are a lot of such jokers on this site.
who cares about that behaviour, though? not me, for sure. hn is just some site, not important in the real world, except for those people who have nothing better to do than hang around here all day or night, and snipe at and try to put down others. iow, trolls and loser types.
as amy hoy said somewhere a while ago, maybe on her site or on twitter, fuck hn.
look, uncle darwin, i discovered a new (creepy) subspecies of homo sapiens, who i hereby name homo intolerantis.
:)
keep downvoting me, bro type, even pull in your friends to do more of it, and thereby waste all your time, and get ulcers and high blood pressure because of my innocuous comment, probably you have a lot of free time because of no job because of layoffs, while i have a good laugh at your stupidity and cheap malice.
It's not that big of a deal... I get downvoted all the time, its just what happens on a social site like this with ratings. Whoever did it probably won't even see your comment anyway
Kernighan was a co-author of the Go book, but I don't know how much he was involved with the actual design of the language. Maybe not much, or at all, although, of course, he is a key part of the original Unix mafia (my term, not pejorative, rather meant admiringly, because I cut my programming teeth on UNIX and C software and books, and worked on that platform a lot, earlier), many of whom are still going strong in their 70s and 80s. So the Go bracket style may not be attributable to him.
https://en.m.wikipedia.org/wiki/Brian_Kernighan
that link mentions many more of his achievements.
that link mentions many more of his achievements.
I read the Elements of Programming Style and the Practice of Programming around the same time and they became completely mixed up in my mind. I'll often remember something from one of those books but be completely unable to remember which one it was from.
Both good books, and both were co-authored by Kernighan. I think they complement each other well.
Both good books, and both were co-authored by Kernighan. I think they complement each other well.
There is a talk he gave at IAS on this. Pretty good one. I think it is available on You Tube.
We might have to add Elements of Programming Style to our backlog.
Well if you're interested, the Elements of Programming Style, to me, was interesting for two reasons. It presents plenty of timeless insights about programming, but it's also very interesting as a historical document; it argues against old-fashioned GOTO-based programming in favour of structured programming, and for-loops executing 0 times, for example.
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.
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.
Because I was curious: https://en.wikipedia.org/wiki/Arithmetic_IF
It's a three way if statement that scrutinizes a number rather than a boolean, with branches for negative, zero and positive values.
It's a three way if statement that scrutinizes a number rather than a boolean, with branches for negative, zero and positive values.
Sounds interesting! We're trying to figure out if we should be focusing on more modern books even if they're "unproven" or classics even if they're outdated. Sometimes reading the classics can be a lot of fun because, like you said, they serve as historical documents. As someone who started their career a lot later, it's crazy to me that GOTO used to be in style, but I suppose for it to fall out of style there had to be a book arguing against it at some point. It'd be interesting to read the original arguments!
Do like the arithmetic if mentioned in a nearby comment, but better :) :
Do all four: modern / classic x proven / unproven.
Choose based on your gut feel plus logic plus reader suggestions.
Why live by constraints? ;)
Do all four: modern / classic x proven / unproven.
Choose based on your gut feel plus logic plus reader suggestions.
Why live by constraints? ;)
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! :-)