101–110 of 169 posts
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.
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.
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.
Previous discussions: http://news.ycombinator.com/item?id=1297536 http://news.ycombinator.com/item?id=3754545
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.
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…
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…
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…
Earlier quoted context omitted.
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…
I'm pretty sure it's the
hardest language to implement
Even scalac and ghc are pretty complex beasts in order to Scala and Haskell reasonably speedy.
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 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.