Books Programmers Don't Really Read (2008) • Hacker News Board

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

#121

Post by pvg » Sat, Oct 15, 2016, 2:16 PM UTC

phaus wrote: post #51

nanolith wrote: post #50

Earlier quoted context omitted.

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

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.

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

#122

Post by hodgesrm » Sat, Oct 15, 2016, 2:33 PM UTC

johan_larson wrote: post #28

GuiA wrote: post #7

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

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…

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

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

#123

Post by rampage101 » Sat, Oct 15, 2016, 2:35 PM UTC

InclinedPlane wrote: post #110

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…

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

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

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

#124

Post by chuymax » Sat, Oct 15, 2016, 3:04 PM UTC

orsenthil wrote: post #5

kuharich wrote: post #2

Previous discussions: http://news.ycombinator.com/item?id=1297536 http://news.ycombinator.com/item?id=3754545

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?

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

#125

Post by kazinator » Sat, Oct 15, 2016, 3:31 PM UTC

vizeroth wrote: post #68

kazinator wrote: post #27

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

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

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.

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

#126

Post by rhapsodic » Sat, Oct 15, 2016, 3:49 PM UTC

InclinedPlane wrote: post #110

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…

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

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

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

#127

Post by ajarmst » Sat, Oct 15, 2016, 4:15 PM UTC

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

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

#128

Post by ssalazar » Sat, Oct 15, 2016, 4:16 PM UTC

tracker1 wrote: post #53

doctorpangloss wrote: post #33

Earlier quoted context omitted.

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

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

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

#129

Post by QuadrupleA » Sat, Oct 15, 2016, 4:23 PM UTC

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.

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

#130

Post by bigtunacan » Sat, Oct 15, 2016, 4:48 PM UTC

sireat wrote: post #96

nanolith wrote: post #23

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

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

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.