It contains interviews with 19 prominent programmers from that era - some of who you’ll definitely recognize. I remember particularly enjoying the Tori Iwatani one - he’s the creator of PacMan.
The full list: Charles Simonyi, Butler Lampson, John Warnock, Gary Kildall, Bill Gates, John Page, Wayne Ratliff, Dan Bricklin, Bob Frankston, Jonathan Sachs, Ray Ozzie, Peter Roizen, Bob Carr, Jef Raskin, Andy Hertzfeld, Scott Kim, Jaron Janier, Michael Hawley
I read this ages ago and thought it might be a rare book - but it looks like used copies are still available really cheaply. Not sure if the second edition had updates - looks like it’s from 1989. Anyway, I highly recommend picking up a copy.
Aside from two readable but not great scans of the two different editions (1986, 1989), with appendices, there's also one version with interviews only that's not scanned, seemingly ripped from Lammers' self-published blog, which is still up but now only has about half the interviews. She probably published all of the interviews there at one point (or else someone reconstructed the missing interviews from the scans while copy/pasting the ones she republished).
I own both, currently reading some chapters from Coders at Work. The interviews in Coders still seem relevant today, but Programmers at Work just seem to be all imperative C code with Hungarian notation, not as relevant to a modern programmer.
I never read that book, but I enjoyed Software Craftmanship"[0].
> “The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.”—Joe Armstrong
That applies to almost every framework and dependency out there.
It's crazy to load a Web page, that adds almost 1MB of JS, so it can animate something that could have been done with a couple of lines of CSS.
A great book. regarding the history of programming languages, and specially getting the realities of languages when they came to be, rather the perception of their capabilities today.
Love Fran Allen's interview regarding C early days, versus other ecosystems.
Something I quote regularly, regarding how C was hardly impressive in terms of performance quality in generated native code.
As anyone coding in the 1980's home computers knows, any junior doing Assembly could easily beat those compilers.
It was the abuse from UB in optimising compilers that eventually made the difference.
"Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities."
The problem is that C compilers have very advanced optimizations. These make the language more dangerous. And yet, the programmer still has to take care of it!
I have a litmus test. Every few years, I compile code which does doubly-linked list operations:
struct node {
struct node *next, *prev;
};
/* Original: pred and succ must not overlap, but this is not expressed. */
void insert_after_A(struct node *pred, struct node *succ)
{
succ->prev = pred;
succ->next = pred->next;
pred->next->prev = succ;
pred->next = succ;
}
/* Optimize with restrict: pred and succ do not overlap. */
void insert_after_B(struct node *restrict pred, struct node *restrict succ)
{
succ->prev = pred;
succ->next = pred->next;
pred->next->prev = succ;
pred->next = succ;
}
/* Optimize by hand in "load-store style". */
void insert_after_C(struct node *pred, struct node *succ)
{
struct node *aft = pred->next;
succ->prev = pred;
succ->next = aft;
aft->prev = succ;
pred->next = succ;
}
I'm consistently finding that the manual optimizations in B and C are required to get the instruction count down.
Simply adding restrict is a simpler manual optimization, but it's dangerous; now demons are allowed to fly out of our noses when the arguments point to overlapping objects, which doesn't happen in function C.
And what's the use of restrict, when I can get the same benefit by coding in a certain way.
I remember that excerpt from her interview and I'm with her almost 100% and yet, if this is another case of worse is better (we had a thread about that recently on HN) then there was a definite demand for C. I was not yet around as a developer but maybe those compilers were too expensive? Did they require too large and costly machines? Did they run on the computer people had at home? Etc.
Thanks. (And I think I've seen you quote that here before. I just didn't realize that this was what you were referring to.)
Next question: How did C do that? By becoming dictator? No, it did it by persuading people that C was a better direction than those other ecosystems. That is, the other direction lost the debate. How and why?
I still don't understand the phenomenon of "worse is better".
My current best guess is a riff on Bob Martin's (?) observation about new programmers (noobs) are minted faster than wisdom of the ancients can be transmitted. An ever expanding circle of ignorance, the center occupied by cranky old people yelling "But you're doing it wrong!" to no one in particular.
So when 'C' emerged, amongst otherwise equal options (to noobs), perhaps it appeared to have both the 'portable' bit fiddly bits (vs ASM) and the structured programming bits of Pascal. And natch, noobs wouldn't be immediately aware of the broken glass and tiger traps.
Further, like with all grifts, there's a turf grab for the new hotness. Something along the lines of "Turbo Pascal was for casuals. Real programmers, like you, should use Watcom's professional new 'C' compiler."
--
I was so enamored with object-oriented analysis and programming. A real zealot. Two (different) friends with experience were "meh". I vividly remember thinking "Those old people just don't get it."
Ahahahah. The folly of youth. Of course, they were proven right. (But also wrong in some ways.)
I try to remember young me now that I'm old, eschewing each new hotness, while trying to keep an open mind, gleaning whatever good bits tumble out.
Worse is better: This can be taken a number of ways. In terms of time (and money), "worse but I can afford it and get it today" beats "better but I can't actually get it". "Worse but easier to use" may also beat "better but harder to use". In terms of writing OSes (which was the use of C), the ability to flip bits and deal with raw memory was very useful. A safer tool might have been "better", but it also could have made it harder to write OSes.
The Fran Allen quote seems to be saying that C made all this promising research stop. Bell Labs did not have armed thugs going out pointing guns at peoples' heads. Why did the research stop, if it was so promising? Because the researchers (many, at least) decided it was less promising - or at least, that more promising options were now available. So if C did that, it did it by either showing that previous directions weren't promising, or by opening up better options. Either way, it's rather unfair to mourn the paths that were not pursued and blame C for it.
It's one of my favorite programming books that makes you realize how quickly you can become confused by the latest trends and shiny new best practices, losing focus on what's important: being a productive and efficient individual contributor when doing something you love
> I must admit, I read this and failed to find any profound, deep way that these coders are different.
I have come to the same conclusion.
> Seems like they just worked hard.
I would like to draw another conclusion. Fitzgerald operated live journal from his bedroom as a teenager - so he was at the brink of new technology. Same effect that gave rise to Bill Gates.
There are probably more effects at play, like working for a company that does not waste your time doing bullshit tasks and having a mentor to get you started. Even a like minded individual will increase your chances to overcome obstacles.
Wow, more than 15 years old. I remember reading it in a vacation and what really sticked with me was that all the luminaries debugged using printf() :-)
Me too - only thing I use a debugger for is analyzing core dumps. Other debugging tools like Valgrind can occasionally be useful to, but honestly a debugger is not the most efficient way to find bugs!
I really liked the stories and most of them are inspirational for me; however I must confess that every time that I read such remarkable histories and those guys doing relevant stuff; I feel bad about the work that I do as a corporate software developer.
My day starts debugging some arcane shell scripts embedded in some yaml in the CI tool; at afternoon I need to optimise some SQL query moving several sub queries that makes the execution plan costly and transform it in small steps in temporary small tables; and before I leave I just noticed some bug in production caused by wrong typing in Go and I need to fix it.
I mean, it’s hard to think about the work that I am doing going towards to a mastery state.
I really appreciate those histories, but for me it’s more or less watching Apocalypse Now from the perspective of a low level cooker/dish washer on the grand scheme of things.
There are many things to be said for and against startups, but working in an early stage (<12 people) startup is wonderful for being able to actually build things.
Bought it just because of the interviews with Knuth and Norvig, but it amazed me how fun and interesting was to read all the other interviews also.
Definitely one of my favorite CS books.
Sadly this book makes me miss what I used to love about programming, and realize just how much programming has stratified into protected roles. The days of one person sitting down with customers, understanding what they need, and then building that solution, seem to be over. Now it's product owners, and business analysts, and testers and developers, and countless sprints and meetings and cargo cult nonsense to get in the way.
I had a discussion with a developer who cut his teeth on mainframes in the 70s. We had the same opinion about today's overly heavy process getting in the way of achievement and talented people. Scrum & Agile have become a quasi-religion and the idea of a programmer saying "leave me alone for a month and I'll give you some software that solves the problem" are long gone. For better or worse.
And before someone says "well, then you're doing Agile wrong." Yes. We are. As is damn near EVERY shop I've encountered in the past 10 years. That's the point. It's a mess and the culture is broken.
Wish we could just go back 20 years and Code at Work, build things that people want and need, and treat it as a craft again.
I know it shouldn't really impress me, but I am nonetheless impressed that I can vote on HN comments from 14 years ago. It used to be that Reddit would make threads read-only after a certain amount of time, and I'm not sure if they still do that. Seems like an indicator of how robust a given site/app is.
Mentioning Reddit, I'm still salty they deleted private messages from before 2023. They couldn't even provide an archive for people to download?!? Utterly bizarre.
This book is still on my shelf. When I first ordered and received it, I sat down and read it cover to cover.
One of the things I really enjoyed was seeing how differently all of the interviewees worked and went about their business. They didn't seem to work that much differently from me, which made their work that much more relatable.
https://www.goodreads.com/book/show/2092681
It contains interviews with 19 prominent programmers from that era - some of who you’ll definitely recognize. I remember particularly enjoying the Tori Iwatani one - he’s the creator of PacMan.
The full list: Charles Simonyi, Butler Lampson, John Warnock, Gary Kildall, Bill Gates, John Page, Wayne Ratliff, Dan Bricklin, Bob Frankston, Jonathan Sachs, Ray Ozzie, Peter Roizen, Bob Carr, Jef Raskin, Andy Hertzfeld, Scott Kim, Jaron Janier, Michael Hawley