Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Books Programmers Don't Really Read (2008)

billthelizard.com

Post reply on HN
Print view View original

51–60 of 169 posts

Re: Books Programmers Don't Really Read (2008)

#51

Post by phaus »

nanolith wrote: post #50
phaus wrote: post #38

Earlier quoted context omitted.

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…

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 b…

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.

Re: Books Programmers Don't Really Read (2008)

#52

Post by TheOtherHobbes »

justinlardinois wrote: post #11
perrygeo wrote: post #6

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

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?

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.

Re: Books Programmers Don't Really Read (2008)

#53

Post by tracker1 »

doctorpangloss wrote: post #33
Godel_unicode wrote: post #21

Earlier quoted context omitted.

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…

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.

Re: Books Programmers Don't Really Read (2008)

#54

Post by catnaroek »

sotojuan wrote: post #16
smikhanov wrote: post #10

Earlier quoted context omitted.

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 te…

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.

Re: Books Programmers Don't Really Read (2008)

#56

Post by nn3 »

taeric wrote: post #48
nn3 wrote: post #40

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

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

Re: Books Programmers Don't Really Read (2008)

#57

Post by nickpsecurity »

justinlardinois wrote: post #11
perrygeo wrote: post #6

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

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?

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

Re: Books Programmers Don't Really Read (2008)

#58

Post by sotojuan »

catnaroek wrote: post #54
sotojuan wrote: post #16

Earlier quoted context omitted.

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 mu…

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!

Re: Books Programmers Don't Really Read (2008)

#59

Post by nickpsecurity »

shagie wrote: post #47
johan_larson wrote: post #28

Earlier quoted context omitted.

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

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 comp…

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.

Re: Books Programmers Don't Really Read (2008)

#60

Post by sotojuan »

Godel_unicode wrote: post #21
doctorpangloss wrote: post #3

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…

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.

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.

Post reply on HN