Live data from Hacker News

Books Programmers Don't Really Read (2008)

billthelizard.com

91–100 of 169 posts

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

#91

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

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.

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

#92

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

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

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

#93
post #91

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

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.

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

#94
post #85

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

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

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

#95
post #22

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…

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.

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

#96

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. Generally you do not read reference books cover to cover

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

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

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.

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

#98
post #12

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

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

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.

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

#99

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…

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

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

#100
post #89

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.

Post reply on HN