Hacker News new | comments | show | ask | jobs | submit login
Books Programmers Don't Really Read (2008) (billthelizard.com)
375 points by jotto on Oct 14, 2016 | hide | past | web | favorite | 159 comments



I've read the books on both of those lists, among many others. Not because these are all required reading, but because I've had a long career and I've fought to continually improve my knowledge in Computer Science. It seems rather arrogant of the author to decree that one list is canon and the other list is not. Each of those books has its use. Does this mean that someone needs to read any of those books to be good at software? Probably not. But, studying each of those books will improve skills in the particular domains that the books cover.

Also, why is it suddenly in vogue to bash TAOCP and CLRS? When I read these sorts of posts, I generally think that the author really means, "I didn't understand these books, so therefore, they must be crap." I started reading TAOCP very early in my career, and Knuth's low-level approach of analysis has served me quite well over the years. It's why, for instance, I don't balk when I need to optimize a computationally heavy algorithm on an 8-bit microcontroller, or when I have to hand-tune a cryptographic algorithm to avoid cache side channel attacks, I can approach the problem logically. Knuth is an excellent teacher for the right sort of student. He's not for everyone, and there's nothing wrong with that. Software ceased being a one-size-fits-all field decades ago. For that reason, among many others, decrees of what is canon or not -- such as the one made by the author of this post -- are nothing but bunk.


He praises almost all of the books on the second list, he just thinks a large percentage of the people that recommend them haven't read much of them.

He also doesn't seem to make the claim that the first list represents "canon" and that the second list represents "non-canon". The first list is a list of great books that are easily understood by most students. Many of the books on the second list are far more advanced.

I agree that some students can learn using any of these resources. However, most people would struggle with books like TAOCP.


He gives some rather backhanded praise for TAOCP, if you can consider noting that a set of books look impressive on a bookshelf as praise. For instance, "I've used my set several times when I was stuck and couldn't find help anywhere else. But TAOCP is always my reference of last resort. It's very dense and academic, and the examples are all in assembly language."

He insinuates pretty strongly that the first set of books is the canonical set with this statement: "If you're interested enough in programming that you're reading this blog, you've probably read most, if not all of the books in this list, so I won't spend time reviewing each one individually."

While not being explicit, he's being pretty implicit regarding his judgement of value for these books.

I don't necessarily agree that TAOCP is especially difficult, but I did say in my original comment above that TAOCP is not for every student. For the right student, working on the right set of problems, I would not hesitate to recommend TAOCP.


You only mentioned the parts of his statement about TAOCP that, when taken out of context, seem to prove your point.

He did note that it looks impressive on a shelf, but he also followed it up with "and it is impressive." Furthermore, he goes on to state that it is so comprehensive that if you have a computer science problem that falls in a category covered by one of the published volumes of TAOCP, and you cannot find a solution in TAOCP, that a solution likely does not exist. That's pretty high praise IMO.

>It's very dense and academic.

Is it not a dense text written in an academic style by an academic known for dense, academic writing? Its likely the greatest reference in existence, but it isn't an easy book to read at all. If it doesn't seem like a challenging read to you, then as the author already stated, you aren't one of the people that he was talking about.

>He insinuates pretty strongly that the first set of books is the canonical set with this statement: "If you're interested enough in programming that you're reading this blog, you've probably read most, if not all of the books in this list, so I won't spend time reviewing each one individually."

IMO, his statement doesn't attempt to canonize them at all. If you look at both lists, one list is obviously far more accessible to the average programmer than the other list. It doesn't make them better, just suitable for different people.

>For the right student, working on the right set of problems, I would not hesitate to recommend TAOCP.

I'm not saying that you're wrong. However, the article is about books that are often recommended to beginners. Most people will struggle if they start with TAOCP.


Is it not a dense text written in an academic style by an academic known for dense, academic writing?

It's not. It's much more mathematical than your typical programming book and it might not be suitable for beginners (it says so itself) but that's not because it's 'dense and academic'. It comes with exercises, historical asides, nerdy jokes and so on.


You're missing the point. He isn't saying the books are crap, not even TAOCP. He is saying lots of programmers suggest they have read them when really they haven't.

You see some of these books suggested to novices. Is TAOCP really the best book for someone just getting started on their first program?


> > For instance, "I've used my set several times when I was stuck and couldn't find help anywhere else. But TAOCP is always my reference of last resort. It's very dense and academic, and the examples are all in assembly language."

Isn't that just agreeing with your point here:

> Knuth is an excellent teacher for the right sort of student. He's not for everyone, and there's nothing wrong with that.


> he just thinks a large percentage of the people that recommend them haven't read much of them.

Donald Trump just thinks a lot of things.

The author never made a valid argument, but lot of people up-voted, an indicator of the growing friction between the plutocrats and the plebeians.


It is strange that someone who read through all of TAOCP and comprehended it would read that blog post so selectively.


"I've read the books on both of those lists, among many others." - I knew this would be the top comment. HN is fast becoming a parody.


In this moment, they are euphoric.


Are you seriously claiming that you have read both TAOCP and CLRS cover to cover?

This is precisely the claim that the original article is talking about.

The article is not claiming that TAOCP and CLRS are bad books. The article simply argues that more people claim to have read the books than actually have read them.

Most of us have read "some" of TAOCP and CLRS.

These are fantastic but rigorous reference works. Generally you do not read reference books cover to cover


You are taking your personal experience; that apparently you do not read reference books cover to cover and then applying it to others.

Personally I DO read reference books cover to cover on a regular basis. I understand not everyone does this, but I don't make judgements or assumptions of others based on this.

I'm have almost an obsessive need to read these things cover to cover. When I hit something I don't understand I reread it until I do or I go look up related materials until I understand it.


True. I'm just reading the Oxford English Dictionary cover to cover, very informative. Just arrived at the chapter on cheeseparing, cheese rennet, cheese renning, and cheesesteak - fascinating, and very useful in my day job.


Heretic! Go back to the basics and learn about the mighty aardvark.


I read most of both of TAOCP and CLRS when I was in my late teens and early twenties. I couldn't follow the most difficult mathematical bits, but I don't think it's THAT unusual to have worked through most of both of them.


In high school read/studied Ivan Hortan's beginning C++ one summer which what an awesome foundation for collage programming courses. Now, I thought it as well worth it and recommended that book to several people. But here is the thing it took most of a summer, and I stopped around page 700 or so. Further I am not recommending someone read it, I am suggesting they spend a few months studding C++.

TAOCP is not a book it's 1/3 of a masters degree in paper form. Suggesting someone read it is like sugesting they get a MS useful, bit not quite the same as recommending a normal book.


TAOCP has four volumes. Its not just a single book. Did you work through all four volumes?


The first three. Fourth wasn't out back then.


> Also, why is it suddenly in vogue to bash TAOCP and CLRS?

I guess for the same reasons people want to bash the current interviewing institution in place.

Personally, I go with "it is what it is, deal with it if you want THAT job"

Back to the context, I think I find CLRS much more approachable than TAOCP. It relies on pseudo-code and fairly simple mathematical symbology to formalise the algorithms it is treating.

With TAOCP I have tried by can't get past the language of the imaginary CPU which it uses.

Also, there are other simply excellent texts on Algorithms which I personally found much more useful than TAOCP (in decreasing order of "easiness")

- Python Algorithms

- The Algorithm Design Manual

- CLRS

- Algorithms in Java (somehow I found CLRS easier to follow than this)

- And then I found this recently, "Algorithms on Strings,Trees and Sequences: Computer Science and Computational Biology" (one should have at least gone through the first two recommendations before starting with this one to make it easier to read this one)

Disclaimer : I have a growing interest in learning Algorithms due to the requirements of interviews, however I have come to believe that the knowledge will go a long way.


My understanding is that the author is arguing that these books shouldn't be recommended reading for everyone.

I bought Knuth's TAOCP and the Cormen book in high-school to prepare for programming competitions. I never read TAOCP and probably never will, it was simply too complex for what I needed.

CLRS was significantly easier to understand and I was able to read subchapters.

Today I use neither, but rather recommend Skiena, Sedgewick or other specialised books. Not because TAOCP and CLRS are bad, but because these other books are more approachable and also get the job done.


I'd never bash CLRS but people suggest in strange situations. It's definitely not a good introduction to algorithms. It does makes sense as a reference and of course as a course textbook. As a book to actually read, Kleinberg/Tardos is much better.


Thanks for the review. I just ordered both.


Cue the circus of people who argue over the contents of this list, despite having actually used the learnings from books only in job interviews.

There are so many developers (like your peers at work) who have literally read none of these books. In a Darwinian sense, isn't that evidence that there's nothing so special about these texts for what you do?

Skip the books and just memorize what's on Interview Cake. I love that site. It so brilliantly subverts the academic pretensions of every industrial software development shop.

So many people will have memorized so precisely the solutions to programming test questions that they stop being useful. Engineering managers will be unable to come up with novel questions, because they will have no benchmarks. Then the madness will end: Computer Science will get less popular in university again, and this notion that these Gospels have All the Answers will go away.


I genuinely feel bad for people who have only used the learnings from these books in job interviews.

Either they've never had to work on a really Hard Problem, or worse they have tried to solve such a problem without the hard-won lessons present in these books.


> a really Hard Problem

I've heard senior recruiters express skepticism about candidates who say they're into "Hard Problems." Experienced engineering managers usually hear that phrase when you're looking for a lifestyle and you don't really care what the application is.

For example, "I have no qualms that your business arbitrages nonconverting clicks from bots and sketchy web traffic (i.e., 99% of the Internet) into Google AdWords revenue, using up a Google customer's ad budget until the customer has barely made a profit... You see, I'm into Hard Problems. Besides, bots don't click twice! It must be real traffic!"

It turns out that junior people on the interview team care a lot more about Hard Problems and the stories in these books than senior people do. And you'd never want your hiring pipeline run by junior people.

In my opinion, Google's focus on Hard Problems has robbed academia of all the sincere Hard Problems people. Then, they've ruined the interview process for everyone else, ironically with the book How Google Works, convincing CEOs that they should be asking about C.S. fundamentals and Hard Problems totally unrelated to their Actual Problems.


To me the funny thing is the small companies with 2-3 developers hiring like they are google with interviews over the course of weeks, with google/amazon-like gauntlets. You aren't google, you aren't paying google-level salaries, why are you pretending you are.

That said, I happen to like problems in general... not necessarily "hard" problems, but just new problems. I also like working in new domains... I mean what other industry of work allows you to work in education, aerospace, banking, security and marketing in a decade and a half.


> To me the funny thing is the small companies with 2-3 developers hiring like they are google with interviews over the course of weeks, with google/amazon-like gauntlets.

Hmm. Arguably small operations need to be more stringent if they are deciding who will make up the next 25%-33% of their engineering workforce. At small companies one bad hire can really poison the well.


True, but they'd probably be better with a hire/fire fast attitude than draw out the interview process... Interviews take time away from the people doing the interviews that can be spent doing other things... do you really want to allocate more than half your company for weeks vs. getting stuff done.

I mean, have a trial period of a week or three... That will tell you far more than a gauntlet interview process with a lot of false negatives.


For me, as a CEO, hire/fire fast is definitely more costly than a well-designed interview "gauntlet"

Before starting my own company I was a bar raiser at Amazon. Interviews were not supposed to last weeks (though many did and there were internal metrics aimed at driving interview to offer cycle time down).

I'd much rather spend a few hours per interviewer per candidate getting a solid candidate than hiring, onboarding, training, learning the candidate is a poor fit, and ultimately going through the not-fun-for-anyone firing process.

High turnover isn't worth the lost productivity from other employees or the hit to morale. On top of that, while learning whether or not the candidate will make it through the trial, you're burning precious cash.

Learn how to interview and teach your people how to interview. It will save you heartache and money.


But do whiteboard exercises that consist of concepts that someone is unlikely to ever touch really count for the quality of code one is likely to output?

Especially when many of those concepts necessitate code that is less than discoverable, well documented and easy to follow?


A 3 week trial period is a far longer than an Amazon interview sequence.


For one person.. not for a few dozen... It's easy enough to pick the apparent best from the available pool much faster.

Also, there's the cost of existing staff in interviews... if you only have 2-3 devs, and you're keeping them all in interviews with multiple candidates, you're not getting work done.


""I have no qualms that your business arbitrages nonconverting clicks from bots and sketchy web traffic (i.e., 99% of the Internet) into Google AdWords revenue, using up a Google customer's ad budget until the customer has barely made a profit."

Can you explain what this business model is and how the arbitrage works? Is this SEO gaming? Thanks


Some people don't care about working in hard problems. They're fine with their Java/.NET CRUD job where you only need domain knowledge and a best practices book.

A large part of the job market has little need for those kind of books.


There's a really small set of programmers who actually need to work on hard problems. The rest of the world just needs their business logic implemented.


Upvote for Interview Cake, that website has been more helpful than most of my CS courses.


I just did the first three problems on Interview Cake. They didn't seem much different from the easy problems on something like Topcoder or Codeforces. Maybe people should just take a moment to solve some of those. Those two also have great communities to help new people.


The Gang of Four patterns book is one of those books that you should probably only read when you already have decent experience writing non trivial software.

If you do so, it will formidably crystallize knowledge you've been acquiring subconsciously. You'll have probably been having gut feelings about why certain things are wrong or clunky and others are elegant, and Design Patterns will give you a vocabulary to describe these things.

If you read it as a beginner, the subtleties of it all will go over your head, and you'll end up trying to cram design patterns everywhere without much sense or reason.


The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence. Think of how few of their patterns have become part of the vernacular of our field: Iterator, Singleton, Factory, Adapter, and maybe one or two more. It's not a long list. If you insist on talking in terms of design patterns, you are going to have to explain nearly all of them to your listeners. Insofar as the authors' goal was to create a shared language of patterns we could use for clearer communication of designs, they fell well short.


Having seen far too many questions on sites about software design where someone starts out with "How do I use a Factory to solve...", I would contend that the GoF had far too much influence and missed the designer's original goals.

> Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

From an interview with Erich Gamma ( http://www.artima.com/lejava/articles/gammadp.html )


Im leaning in that direction. Beginners did much better with methods like Cleanroom since it was all straight-forward decomposition of modules into easy-to-verify functions and acceptance tests. Amateurs trying to apply patterns often plaster them everywhere in designs that sometimes make structured programming in BASIC look more readable.


> The problem with the design patterns books (including the GoF one) is that in the end they didn't have much influence.

Really? The Gang of Four book was my favorite programming book from the 1990s. A lot of people read GoF as a cookbook which I think devalues it and leads to a very dogmatic design approach. The message I got from applying GoF over a period of years is that there are existing, flexible patterns that you can use to organize large object oriented systems, though they don't solve nearly every problem and you'll need to tune them for each design. Viewed that way it's a work that can give you inspiration for decades.


Some patterns have become parts of languages and libraries as those evolved. Subject-observer lives on in Qt's signals and slots and in general any signal/slot library. Command is basically operator() or std::function in C++. Null object is a useful little trick.

I'd also add Facade and Strategy to your list.

It's indeed not long but it does save some time when talking about design and various potential solutions. That's good enough for me.

P.S: I think head first patterns should be preferred to the GoF book if one insists on learning from a book, but otherwise they can be grasped from a Wikipedia article.


I think Game Programming Patterns is an excellent read for learning patterns


The GoF design patterns book has two core, very closely related, problems.

The first is that it doesn't make enough of an effort to present "design patterns" as a conceptual framework. Can you program without using design patterns? No, you cannot. You are always using design patterns whether you know it or not, you're just using ad hoc design patterns without realizing it when you don't think you're using patterns. The book's failure to elucidate commonly used ad hoc patterns as well as common anti-patterns is one of its principle shortcomings. This is something that the refactoring book did much better, by providing examples of how things can be engineered in different ways and why one way might be desirable over another (and how to transition between them). Instead the GoF book largely presents a canonical list of some design patterns, giving people the false impression that these are special and unique versus merely a sampling of ways one might do things.

Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not. The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written. Many of the design patterns aren't necessary outside of that environment. For that reason, a lot of the design patterns in the book are either obsolete or so seamlessly built in to popular languages that it's not necessary to implement them as described in the book. Many of the more advanced "behavioral" patterns from the book are essentially ways to work around the fact that Java didn't have first class function, when that changes the design patterns that you end up with become very different.

A lot of the GoF's list of design patterns just aren't that useful anymore in modern languages, even though many of them are as applicable as ever (modern languages bake iterator support into the language, for example).

Additionally, the GoF design patterns break down into two categories: everyday patterns (like iterator, factory, proxy, or adapter) and sometimes patterns (like flyweight). This means that most of the patterns shouldn't be used in every project. Because the design patterns in the original book are somewhat out of date and because there's been so much cargo culting around the GoF patterns there's grown a substantial backlash against patterns. So people tend not to describe new patterns in such a way, even though they should. The concept itself is quite sound, but it requires diligent effort to ensure you're applying it well.


> Additionally, the GoF book doesn't make it clear that each design pattern exists to work around specific constraints, and thus doesn't educate the reader when and why the design pattern should be used, and when not.

Quite to the contrary. I don't have my copy handy and haven't cracked it open in years, but I recall clearly that they presented design patterns as reusable solutions to commonly occurring problems. And for each pattern they outlined, they explained what the problem was that it was intended to solve.

Alas, the part about patterns being solutions to specific problems was lost on many developers, who shoveled in applications of patterns where their corresponding problem didn't exist. And rather than a more modular, understandable, maintainable codebase, an inscrutable mess was often the result.


I do have my copy at hand. While they do try to get across the concept that not all patterns are suitable for all cases they do a remarkably poor job of it. The "applicability" section of most described patterns is a simple bullet list of 3 or 4 very vaguely worded sentences. This is, as evidence has proven, wholly insufficient. There should have been much more effort into trying to educate readers on the applicability, and non-applicability!, of each pattern, explaining the constraints that made the pattern necessary or desirable, laying out examples of other ways to achieve the same functionality, and also explaining the costs and extra complexity of relying on a specific pattern.


YMMV, I guess. I thought they laid it out all pretty clearly.


"The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written."

The book is about C++ and Smalltalk. There is not a single mention of Java in their book.


> The GoF list of design patterns is very much tightly coupled to the peculiarities of Java at the time the book was written

GoF publication date: 1994; Java launch date: 1995

The patterns are essentially Smalltalk-based, though the authors had been implementing the same ideas in C++ - Gamma in ET++ and Vlissides in InterViews.


I agree with your second paragraph, but I also think that as with every book, you have to understand the context it has been written and it is always good to have a wider picture and know how something can implemented using a different paradigm and how things relate to each other.

I am not sure I can agree with the claim that everything written is following some design pattern. Perhaps it is an known anti-pattern instead or completely ad-hoc solution that is neither but is nonetheless a good design.

Design patterns are architectures that have been distilled from the field experience to be useful to solve certain problems resulting in a good design. Therefore it is also quite natural that they get integrated into language designs over the time.


Have you read Design Patterns? The viewpoint you have here is typical of people who have absorbed it osmotically from software culture, but haven't read the work itself. You say:

    > Instead the GoF book largely presents a canonical list
    > of some design patterns, giving people the false
    > impression that these are special and unique versus
    > merely a sampling of ways one might do things.
From the Introduction:

"Despite the book's size, the design patterns in it capture only a fraction of what an expert might know. It doesn't have any patterns dealing with concurrency or distributed programming or real-time programming. It doesn't have any application domain-specific patterns. It doesn't tell you how to build user interfaces, how to write device drivers, or how to use an object-oriented database. Each of these areas has its own patterns, and it would be worthwhile for someone to catalog those too."

    > Additionally, the GoF book doesn't make it clear that
    > each design pattern exists to work around specific
    > constraints, and thus doesn't educate the reader when
    > and why the design pattern should be used, and when not.
"No discussion of how to use design patterns would be complete without a few words on how not to use them. Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed. The Consequences sections are most helpful when evaluating a pattern's benefits and liabilities."

Literally every single pattern chapter in the book comes with an explicit section describing when you should and should not use it.

    > The GoF list of design patterns is very much tightly
    > coupled to the peculiarities of Java at the time the
    > book was written. Many of the design patterns aren't
    > necessary outside of that environment.
As another commenter noted, Design Patterns is older than Java and makes no mention of it. The patterns are often particular to object-oriented languages, but I don't know what else you would expect from a book titled "Design Patterns: Elements of Reusable Object-Oriented Software".

    > Many of the more advanced "behavioral" patterns from
    > the book are essentially ways to work around the fact
    > that Java didn't have first class function, when that
    > changes the design patterns that you end up with become
    > very different.
The book uses Smalltalk as one of two example languages. Smalltalk not only has first-class functions, but all blocks used for control flow in Smalltalk are essentially closures.

The Command pattern isn't just "how to take first-class functions in a language that doesn't have them". It also talks about commands that are undoable, or that can be logged, or serialized and deserialized. It's as much about the objects that create the command, receive the command, and have the command invoked upon them as it is the command itself.

I do wish it talked more about the relationship between commands and first-class functions (which I do here[1]), but it's not as bad as you make it out to be.

[1]: http://gameprogrammingpatterns.com/command.html



The same might apply to Head First Design Patterns:

https://blog.codinghorror.com/head-first-design-patterns/


I think those books have a specific time* in people's careers. My first real programming job, a couple years in i got a large project. I'd go home and flip through the design patterns book every day. Some days, rereading the introduction, some days rereading patterns. The project came out pretty well.

If i'd gotten a C++ job instead, i'd probably have torn up the C++ programming language book. My copy is fairly worn, but not like that gof book.

CLRS probably isn't as helpful as it once was, because the vast majority of time you just use an ADT from whatever library your language provides. Sure, maybe go review some subtleties from time to time, but if you're writing an algorithm for work, you probably do that all the time, CLRS isn't going to be that insightful.

The dragon book was opaque to me. Just about every thing in that book, i had to go find another discussion of. I'm just not smart enough to parse those words and math into code.

I dunno. I'm a pretty mediocre programmer. They've been helpful to me at various points in my career, but i don't think they are much help in modern programming.

* I've only been able to chew through a couple chapters of TAOCP. I think the only programmers these books help are people like Fabrice Bellard. Find someone who's worked through those books, hire them. Well, if you really need to solve problems and you're not just hooking a submit button to mysql.


> I think those books have a specific time in people's careers.

Agreed. Code Complete gave me a huge boost as a liberal arts refugee in computing. Having given away my copy, I bought the second edition, thinking it would be worth a reread. Not so much. Pragmatic Programmer didn't do much for me either, probably because I read it too late.

On the flip side, plodding through TAOCP just because? Better to read the relevant chapters when you've got an actual project to chew on.


Interesting. After reading Code complete (2nd) I felt that I didn't get much out of Pragmatic programming either.

One question that keeps popping into my mind is what books and in what order should one feed an inexperienced junior to turn them into a mature software engineer.


I don't think there's a curriculum you can set up. For me, the best books were books that talked about problems i was having at the time.

For example, my biggest take away from Code Complete was the stupid slow but easy to test implementation of the excel calculation engine. I was working on a print system at the time, building a stupid system and a fancy system and comparing the results gave me a lot of insight about what was wrong with the fancy system.

Me personally, i got a ton out of the lisp books PAIP, SICP, On Lisp, and even the CL spec. Thinking about something in terms of stream processing or unification from the various prolog implementations would get me started on answers to problems i was facing (they never required unification).

Just blindly handing out reading, i'd probably give people _The Phoenix Project_. Most organizations are a mess, and new programmers don't understand that. The down side is, new programmers can't do much about it. It can help explain why you do some painful stuff though, like on call or code reviews.


> I've read all of these books myself, so I have no difficulty believing that many moderately competent programmers have read them as well. If you're interested enough in programming that you're reading this blog, you've probably read most, if not all of the books in this list

That is some gross arrogance on full display right there. If you're as good as me, surely you've read all these books. Any other books... flawed in ways you should be ashamed of.


I don't believe the author intended to insult you. It's very likely you do know much of what those books have to offer. It's also possible you think about the topics in those books in a different manner. One of the benefits of a group of programmers reading the same book is the shared language.


That incidentally is the idea behind Patterns... not this "pick a pattern to solve the problem" - or worse yet, "here's a Pattern, find the problem to solve."

The shard language. The GoF wanted that shared language, but people missed the ideal behind it and thought it was a cookbook instead.

The GoF draws from A Pattern Language ( https://www.amazon.com/dp/0195019199/ ) and I believe does a better job at communicating what Patterns should be - a common language and broad brush strokes of solving common problems (though almost always require some tweaking to make it fit just right).


He said "arrogant" not "insulting".


It isn't arrogant to assume other people are at least as well read as you are. It would be arrogant to assume that they aren't.


Agreed. At risk of sounding like an idiot, the K&R C book and Mythical Man-Month are the only books on that list I've even heard of, and I haven't read either of them.

Also, he gives "more of a language reference" as a reason for not reading Stroutstrup's C++ book. Doesn't the same apply to K&R?


C is a far smaller language than C++, and perhaps the writing style of K&R is somewhat more accessible. Stroustrup's book does have some parts that give an "I invented this language, see how awesome it is" impression, whereas K&R is quite unopinionated and neutral.


K&R actually describes C. You can pick up the original K&R from way back, and it's not so different to the latest ANSI C. The differences aren't quite trivial, but they're not so big they're going to distract anybody for long.

It's probably impossible for any book to fully describe C++ because it'a a perpetually moving target on a three year update cycle.

There are always new idioms and techniques to learn, but they keep being changed/added without any obvious coherent design strategy or logical goal.

Books can barely keep up. Stroustrop's own C++ introduction is for C++11, which is already five years and nearly two releases old.


For a long time this wasn't really the case. In between C+98 and C++11, Stroustrop's book contained essentially everything you would want to know about C++, including details on how to implement the STL yourself!

The end of the book even included a grammar for C++ (with a slight comment about how the grammar wasn't exact because of C++ context sensitivity)


No. Save for the appendices, K & R can be completed and understood in a weekend. It's kind of fun to read and to work through the problems, even if you rarely use C. The Sepples book, on the other hand, is an encyclopedia. I don't know why anyone would want to read that unless he had to.

In 2016, however, I think that a lot of people would have read CLRS, even if they haven't read ALL of it. It's used as the reference text by a lot of university courses on algorithms.


This is a good reading list. You should probably pick up a copy of these, flip through them and see why they are so recommended. Having not done something doesn't make you an idiot. Having an opportunity and a recommendation, and rejecting it for no good reason... that could be different.


Definitely read Code Complete and pass it onto junior developers. Many teach you how to write code but it breaks down writing maintainable code.


I'd put SICP on the better read when dead list. Fundamental Algorithms shouldn't be read anymore but at least I liked it when I read it. SICP was the text in 61A at Berkeley but there were no assigned readings from it. It was meant to be worshipped rather than read. I rather like the Dragon book but compilers have come along. The 2nd edition is an improvement.

I'd add that EE20N used a Berkeley written text, Structure and Interpretation of Systems and Signals. I was in the minority and liked that book. I still have it.


I read SICP for the first time in February this year, 15 years into my programming career and 12 years after graduating from a CS department. It's a very easy and enjoyable read, even the code blocks are readable, unlike coding examples in most (all?) modern programming books. I literally loved every page of it.

There's just something special in the way material is presented in SICP, in the order of topics, in the text's tone: it remains enthralling without being difficult, it teaches without being indulgent. It absolutely is meant to be read.


The tone of the book is that of learning programming and computer science for enjoyment, learning, and fun. That's what makes it timeless.

A "stronger" example of this tone would be The Little Schemer series.


Sadly, SICP is lacking in mathematical rigor. Often, the book rushes to give broken code snippets based on insufficiently deep analysis of the problem at hand (e.g., interval arithmetic in chapter 2), and the exercises consist in fixing the code after taking additional information into consideration. It would be preferable to first carefully write a formal specification, and then write the right program without so much trial and error.


To be fair, it was written to be a student's first introduction to computer science. I think it's fine if you don't have to prove everything.

Ironically, Chapter 1's reliance on math for examples and exercises turns people off!


This is getting it backwards. The first introduction to CS is precisely when proofs matter most.

I agree that, ultimately, not everything has to be proven correct. Often there isn't even a well defined criterion for software correctness. But proofs absolutely matter in certain domains (algorithms, databases, compilers, etc.), and there's no way you can be ready to prove things about moderately tricky programs if you don't have practice proving things about toy ones.


Heh, sounds like the classic undergrad approach to textbooks. Having skipped out in CS as an undergrad I am currently reading SICP to fill in gaps that I have missed and have found it to be a great read and the problems to be enjoyable. Frankly, I can't imagine going to class being more effective than reading the text (assuming you do the problems in either case).


Have to agree with this. Having gotten my education well before SICP became a thing, I fail to see anything special or even particularly interesting about it.


Which book do you think is a better introduction to computer science?


I've read CLRS page-to-page 3 times and doing pretty significant chunk of exercises. It takes on average about 4-8 months with 2 hours each day. I still think the title is accurate, i.e., its just "introduction". These days at work I frequently bump in to algorithms that would be qualified as advanced and CLRS content now looks fairly introductory to me. In fact book hasn't even scratched 10% of the stuff that we use regularly in our work. I think most people active in CS research feel the same way but if you were programmer doing regular LOB or iOS apps then OP's view may feel more closer.


I'm curious, what do you do at work and what kinds of algorithms do you bump into?


computer vision, machine learning, control software and things around that.


CLRS is even great to skim. I always find it tremendously helpful to skim through when preparing for interviews. It provides a great survey of commonly encountered problems, so you can use it to diagnose your problem areas.


The whole article just seemed like one silly anecdote. "Well these are the books I actually read so it must be the same for everyone."

I think the author's next read should be a good statistics book.

Here's my anecdotal evidence. I have read 8 out of 10 from his first list. I have read everything except for TAOCP from the second list. Some of the ones from the second list I have read multiple times and I still go back too as reference from time to time.

I have started reading TAOCP on several occasions, but I'm not going to lie; that shit is complicated and the dry academic nature makes it even worse to parse. I still plan to get through it in my lifetime, but I keep prioritizing easier reading.


> Periodically over on Stack Overflow (and in many other programming forums) the question comes up about what books are good for programmers to read. The question has been asked and answered several times, in several different ways. The same group of books always seems to rise to the top...


> There's certainly plenty of evidence that someone has read this book, since otherwise we wouldn't have so many C++ compilers to choose from.

I don't think that's quite true. The only C++ compilers I know of are:

1. cfront C++ (from which many C++ compilers were derived)

2. Digital Mars C++ (the one I wrote)

3. g++

4. clang++

5. EDG C++ (from which many other C++ compilers are derived)

6. Microsoft C++

7. Taumetric C++

It's a pretty thin list for 30 years. (I apologize if I neglected any.) Contrast that with C - at one time in the 1980s I counted over 30 of them (I'm not sure how many were independent creations).

Edit: removed Borland C++ as that was derived from Taumetric.


Maybe Intel C++ as well? But most people who have that book didn't buy it to write a compiler. Isn't C++ ridiculously hard to write a compiler for? While I haven't written one, I think it'd be much easier to write one for C — and for that I imagine it would very nearly suffice to have the K&R book.


Every C++ front end I know of has at least 10 man years in it. I'm pretty sure it's the hardest language to implement, by far. (The core language.)

Ironically, one of the hardest things about a C compiler is the preprocessor. You'd think a text macro processor would be simple, and it should be simple. There's an amazing amount of subtle complexity in just the handful of pages describing it in the Standard.

I and many others implemented a C compiler based on K+R, and I can attest that a lot of rework can be avoided if following a Standard instead (C89 did not exist at the time).


   I'm pretty sure it's the 
   hardest language to implement
Harder than languages that require JIT compilers to achieve reasonable performance?

Even scalac and ghc are pretty complex beasts in order to Scala and Haskell reasonably speedy.


I've written a Java compiler, and a friend of mine (Steve Russell) wrote the JIT for it (for Symantec). It was the first JITting Java compiler, and took only a few months to complete.

Of course, I should have said "front end". Working on the optimizer/codegen is an endless process.


Yes, C++ has a baroque syntax, and I wish lexing/parsing C++ on nobody.


I read the comment as saying C++ is the hardest language to implement, not the hardest language to make fast.


Speed and type-inference are the two hard things in compilation in my experience.


You can sink 10 years into just about any software to make it run faster. I wouldn't think that reflects on the inherent difficulty of writing a compiler in the abstract.


Sure, but a simplistic C++ compiler will still produce code of acceptable speed. The same is not true of simplistic compilers for languages like Javascript.

Meta-tracing a la PyPy is such a revolution because it enables low-cost creation of reasonably performant tracing JIT compilers.


Their comment doesn't make sense to me. Someone working on a compiler would use the standard, right?

The book is for the people wanting to know every corner of the language. Unfortunatley I read it a long time ago and don't remember if it's enough for that purpose or one still needs Meyers and maybe some other resources.


> Someone working on a compiler would use the standard, right?

Today, yes. But in the olden days of C++, there was no standard and people used Bjarne's book.


9. Intel C++ 10. Watcom 11. IAR 12. Commeau etc.


Intel is derived from EDG. Commeau is derived from Cfront. I don't know anything about Watcom C++.


Years ago we had some banned C++ features Because they didn't compiler properly on HP-UX compiler. But maybe that was still part of the g+ umbrella


I have a hard time believing Petzold's Code is in the first list, or even the second, because its content is so very different from most of the other books. It's not particularly directed at programmers either.

As for the design patterns book, I've glanced through it and didn't find it all that useful; that being said, I was never a fan of that school of thought (OOP, UML, patterns, etc.) either.


I bought Code as a gift to my mother, who is absolutely illiterate on computer science. She was thrilled to have learned about morse and binary code. She didn't get too far on the book, though, mostly because she is not completely fluent in English (and it's definitely a difficult read for non-programmers). But yeah, I agree this book shouldn't be on either list.



Wow! did not know that this surfaces time and again. I think, we need meta-post which says Posts that HackerNews readers don't really read.


Add the article on Big O notation to that meta-post please!

Maybe it's the influx of new people to the site that upvote these articles?


How do you keep track of previous HN threads about a URL ?


Click the "past" link at the top of the thread. Very useful feature added some months ago.


> If you're interested enough in programming that you're reading this blog, you've probably read most, if not all of the books in this list

oh, really?

> it's intended for the multitudes who are trying to appear smarter by pretending to have read them.

As opposed to trying to appear smarter by issuing decrees to the internet about what everyone who is "interested in programming" has read.


I think part of it was that this was written in 2008 which is forever ago in internet time. I think book learning for programmers was maybe more prevalent back then. I know I was significantly more likely to read a programming book 8 years ago when the quality of information on the internet was much lower (2008 was the year Stack Overflow was founded!)


I was thinking that too. The younger developers I know haven't read most of those books because the information is easily accessible on the web.

When I started coding professionally you had to buy books because the information wasn't anywhere else, but today even for the more difficult subjects you can find papers and blog posts and wiki articles that cover what you want to know at different depths and from different angles.


Most of the information that makes some of those books worth reading is only easily accessible on the web in the sense that it's pretty easy to find ebooks of many of those books on the web.

Many people learn a lot of their development knowledge from the web (and I certainly do as well), but the majority of the web sources for material beyond basic language reference simply extract the easiest to digest parts of the major texts. This is why so much of what many people know about patterns, algorithms, data structures, and even OOP, TDD, Agile, Scrum, etc. is fragmented or even wrong.


From the first list, I've only read (3) The C Programming Language and only partially (5) Mythical Man-Month.

From the second: (1) Intro to Algorithms, absolutely cover to cover once, and selected readings additional times; based the Kazlib "dict" module closely on the Red Black tree algorithm (with a slight improvement); (2) Compilers: Principles, Techniques and Tools: Ditto, and in recent years, implemented a regex compiler based on the graph-based descriptions in that book; (3) TAOCP: selected readings only, too huge; (4) Design Patterns: cover to cover, when OOP was fashionable in the 90's; (5) nope, but I read the Stroustrup and Ellis Annotated C++ Reference Manual cover to cover (weekend before starting first C++ gig). That counts as a 1:1 substitute, more or less.


Most of the books on the first list represent those I would only read once, and never again (or never at all, like "Head First [Anything]"). The C Programming Language and Refactoring are the exceptions. K&R was one of the textbooks in my first CS class, and the first CS book I read which was still useful to me 10 years later.

The books on the second list which I have read (at least partially) are books I have had reason to go back to at some point in my career, and any of them which I no longer have, I will likely purchase again.


About the K&R2; I have no idea where my old copy is, but I know the precedence table is on page 53, and that I found an ISO conformance bug in example code on page 117: modifying an argv[] pointer.


> the word "Introduction" leads one to believe that the book is a good choice for beginning programmers. It isn't. The book is as comprehensive a guide to algorithms as you are likely to find anywhere. Please stop recommending it to beginners.

Reminds me of the Caltech required 3rd year math course "AMa95 Introductory Methods in Applied Mathematics", that came with the dry comment that "Introductory does not mean elementary." It had a reputation as one of the toughest classes.


It sounds like they're actually conflating the two words in question. Introductory means an introduction, like the thing that helps you get into a subject. Elementary means basic or foundational. Logic and set theory are elementary to the rest of mathematics. They're not introductory to the rest of mathematics.


They meant do not infer it to be an easy class.


>On the positive side, if you're looking for the solution to >a problem in TAOCP (and the appropriate volume has been >published) and you can't find it, the solution probably >doesn't exist. It's extremely comprehensive over the topic >areas that it covers.

That's almost certainly wrong. TAOCP is very outdated in many ways and doesn't really cover modern algorithms. It's great for classic CS upto 90ies(?) or so, but there has been a lot of progress since then.


What do you feel it is missing? Better, where has it really been left behind?


- probabilistic algorithms (like all the modern bloom filter variants or skip lists or treaps) - parallel algorithms - cache oblivious (or just aware) algorithms. This made a lot of difference in designing trees or graphs. - modern hashing (like cuckoo or robin hood hashing), or min hashing - data mining algorithms ...


Are you sure those are not covered? I know he covers Bloom's filter. And half his treatment on trees is how frequency of access matters on tree creation. (He specifically does not advise just balanced trees.)

For hashing, he does cover things at arms length.


All these things only came out after 2000. Basic bloom filter is earlier, but modern bloom filters (and varieties like cuckoo filter) have improved quite a bit. The standard paper on modern bloom filters came out in 2006.

It's also true for other areas. Let's take sorting. The best general purpose comparing algorithm is timsort. timsort came out in 2002.

Keep in mind TAOCP was originally published in the early 70ies (first book came out in 68) and even though there were some new editions (upto late 90ies) they didn't really change all that much.

You can just scan over TAOCP's bibliography and see the average year of the cites. It is usually 60ies.

Claiming that CS has not improved since the 60ies is fairly absurd.


I won't claim it hasn't improved. I will claim there are a lot of rediscoveries.

Still, your point is fair. The section on secondary key retrieval is very high level. Bloom filters get just two paragraphs.

I think the biggest change in cs is the view towards memory. In much of TAOCP, care is given to the memory footprint. Much of day to day programming is completely ignorant of memory. Scarily so.


I do like the C++ programming language book. It has a really nice introduction in the first quarter of the content. It has good no nonsense examples.


Let's see.

Never come across Code, Head first Design Patterns - WHY? GoF book is much better, and well written and explained. Read all the rest, though K&R 1st edition. Bought 2nd when someone 'borrowed' original from my desk and never returned.

Of the rest:

Never heard of the first one, but I'm British.

My green dragon book was read cover to cover a couple of times, and I tried to build a compiler off the back of it. I used another compiler book in equal amount, I forget the book though.

I've three volumes of Knuth. I should have bought one at a time - I got about 1/2 way through the first volume.

Design patterns was extremely well used.

C++ was mainly reference, unlike K&R it wasn't a good read to learn from. Pretty heavy going if I remember. The Design and Evolution of C++ was much more interestng. Then the 2 Scott Meyers books (Effective C++ 1&2). Thinking in C++ was the book recommended to learn from at the time, though I've not read this.


What does it say about me if I haven't read any of those books?


It says that you have not exhausted the wonders of this world, and that good times are ahead of you.


Who claims to have read a book they didn't? "Yea I read that." (No I didn't). That's straight lying.

I think what's more likely is, someone will say, "YOU should read this book. It's awesome." The implication being, the suggestion comes from first-hand experience.


When I started programming, I first read "Beginning Programming For Dummies" (QBasic), "C++ for dummies" (before STL, so implementing your own linked lists was fun), and... The C++ Programming Language

I spent maybe 3 years as a kid flipping through the C++ Programming Language book, trying to figure out how to do stuff with that + the Allegro tutorial. Totally a programming language reference.

It's one of those weird books that you could spend years just looking at on a desert island and find things to do with it. But you basically need to flip through all of it to get what is happening most of the time (at least I needed to when I was a kid).

Really wish I knew about Python back then....


Wanted to second the ambivalence around the CLRS Intro to Algorithms book - having learned a few algorithms by poring through its chapters, I can definitely say it's a long, out-of-the-way route to take for a practicing programmer. I may not have enough hindsight (bought it a year ago) to truly say whether the dense mathematical approach was valuable to me long-term, but for now I'd say a wikipedia article or a less formal, more to-the-point book like Jon Bentley's Programming Pearls is time much more well spent, unless you are actually aiming to work in academia for a computer science department.


TAOCP is so much superior to CLRS it is not even close. At the end of each section of CLRS they ususally mention Knuth anyways.

Knuth's writing is clear and amazing. It really makes the history of computer interesting.

Pretty typical of the author of the post who did not complete TAOCP to say it is somehow flawed for being too cryptic.

Why is the author concerned about what others have read or not anyways? It seems he more concerned about proving he has read more than others.


Is there a good alternative to "Compilers: Principles, Techniques, and Tools"?

I've been programming for a few years now and I'm looking to more formally educate myself in general computer science. I've been told having a good grasp on compilers and interpreters can be useful for a wide variety of problems.

So far "Language Implementation Patterns" looks like it might be a promising alternative.


I highly recommend Modern Compiler Implenentation in ML by Andrew Appel (he is also an inventor of a number of important modern compilation techniques).

I also rather enjoyed Crafting a Compiler. I found the explanations and excercises to be much more practical and enjoyable than the dragon book, but the code authors present is mostly garbage and full of global variables, state mutations and design pattern heavy. Ignore the code and do the excercises yourself.

I always found the Dragon book to be too parsing-heavy which gets boring quickly. The books I listed spend far less time on parsing and much more on code generation and optimization which I find more enjoyable. YMMV.


Another book that's really good it Types and Programming Languages. It goes over how to define the operational semantics of a programming language, and then gives examples of how to implement them.

It pretty much just glosses over parsing etc., and focuses on the semantics of a language, which IMHO is much more interesting.

Sure, if you're building a real language implementation, you will need a parser, but in a lot of ways it's the least interesting part.


Read "Let's Build a Compiler" by Jack Crenshaw http://compilers.iecc.com/crenshaw/


Give SICP a try. Then, pick up the dragon book if you enjoyed SICP. It's a different experience after that.


Thanks. I've heard good things about SICP and that it pairs well with "The Little Schemer" and "The Seasoned Schemer".


Also Essentials of Programming Languages (also by Dan Friedman), which talks specifically about language design and compilation/transformations.


I read the Dragon book, actually studied it for a CS course. I read C for the same reason and because it was the time when either you read books or you didn't know stuff. Most of the other books are more recent and the web was already there and good enough, especially for references. Those get old fast on paper.


CLRS and TAOCP don't really get old that fast.


CLRS is from 1990, too late to my party: I was through most of my CS courses by then and who could have known about it on my side of the Pond and in a different language? Some of my teachers probably, but maybe nobody as soon as I graduated and got a job.

Instead I knew about TAOCP, also because of TeX. Not a required read in my CS course. We had a smaller book, Wirth's Algorithms + Data = Programs. I skimmed through the TAOCP volumes available online but it takes really a lot of dedication to read substantial part of those books and I think that the impact on my work would be minimal nowadays.

But yes, by the look of them both those books will be relevant for a while.


Reading these books leads to the opportunity to take on jobs related to these books. So people saying, "oh, I use this in my job all the time" without reading the books after they took the job, ultimately have less to say on the matter.


Is Code Complete still worth reading for a working developer?


I think so. A lot of the recommendations are based on research and, at the very least, it helps strengthen knowledge that you may already have. I learnt a lot from Code Complete when I read it.

It is also an easy read - its not a hard academic book.


I'm a working developer who has read Code Complete. It's definitely worth reading. It's the only book on my bookshelf at work that isn't internal documentation or my own notebooks.


I read the first edition (haven't read the 2nd yet) in 2000, and it really shaped the way I've written code since then, even though I work primarily in untyped web languages like Ruby and CFML.


I didn't think it was ever worth reading. Steve Maguire's "Writing Solid Code" was much better, though TBH it's been so long I have no idea how it holds up.


I've read both, and while Code Complete covers a LOT of ground, I like Maguire's style and his practical information. I wouldn't want to be without Code Complete, but Writing Solid Code (and his followup, Debugging the Development Process) has plenty of decent info. And some dated.

Much of Maquire's coverage is VERY C++ centered, so people using anything else are going to skip a bunch. It's a short book, 250 or so pages, and an easy read.


all 5 of the books mentioned that programmers dont read were required reading for my CS degree. Did I read them cover to cover? no but i did read enough to say which are useful to read and which are not. I would guess the majority of programmers who have completed a CS degree have only read those books because they were required reading, does that make the books less important or useful?


Wow I've read many more of the books in the second list.

The second list should also include Structure and Interpretation of Computer Programs.


I missed the part where the author provides a reference/source to claim that developers don't really read some books.


I've read all of 3/10 books on the first list "everyone reads", and 3/5 on the "no one reads" list.

Most of the books on the first list were published after veterans already learned the relevant materials -- the author must be under 30 (so under 25 at the time).

Certainly a weird sample among popular books, the author thinks everyone reads the same arbitrary subset of books he had.


>programmers tend to read programming books instead of computer science books

Wow, amazing insight!


How about Clean Code?


It was only published a couple months before this blog post was written.


Ah, another entry for the "I didn't read the books people say I should have---here's my nationalisation" genre.


Sigh. *rationalisation. Doesn't really help your snark when you emit a silly typo.


Interesting. I've read almost none of the books on the first list, and everything but TAOCP on the second.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: