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

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

#141

Post by taeric » Sat, Oct 15, 2016, 6:48 PM UTC

nn3 wrote: post #135

taeric wrote: post #131

Earlier quoted context omitted.

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…

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.

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

#142

Post by ori_b » Sat, Oct 15, 2016, 7:14 PM UTC

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

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

#143

Post by sedachv » Sat, Oct 15, 2016, 7:49 PM UTC

RandomOpinion wrote: post #13

CalChris wrote: post #8

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

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?

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

#144

Post by fooker » Sat, Oct 15, 2016, 7:55 PM UTC

FabHK wrote: post #138

bigtunacan wrote: post #130

Earlier quoted context omitted.

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

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.

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

#145

Post by tracker1 » Sat, Oct 15, 2016, 8:19 PM UTC

ssalazar wrote: post #128

tracker1 wrote: post #53

Earlier quoted context omitted.

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.

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.

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

#146

Post by wtetzner » Sat, Oct 15, 2016, 8:21 PM UTC

mafribe wrote: post #109

WalterBright wrote: post #94

Earlier quoted context omitted.

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…

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 read the comment as saying C++ is the hardest language to implement, not the hardest language to make fast.

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

#147

Post by WalterBright » Sat, Oct 15, 2016, 8:28 PM UTC

mafribe wrote: post #109

WalterBright wrote: post #94

Earlier quoted context omitted.

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…

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.

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

#148

Post by wtetzner » Sat, Oct 15, 2016, 8:29 PM UTC

stass wrote: post #72

drew-y wrote: post #20

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

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.

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

#149

Post by WalterBright » Sat, Oct 15, 2016, 8:29 PM UTC

c3534l wrote: post #136

WalterBright wrote: post #81

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

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.

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

#150

Post by mturmon » Sat, Oct 15, 2016, 9:04 PM UTC

eicossa wrote: post #104

kuharich wrote: post #2

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

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.