The author's point, summarized, is "Don't recommend books to new programmers that you haven't read yourself". My recommendation is to go read those books that you recommend. Even if you read them after you recommend them.
Did you ever see that stack overflow post which says in dozens of ways that you can't fully take apart (parse) HTML with regular expressions? If not, you should. It is informative and entertaining.
Don't you think that if those who attempt to separate HTML with regular expressions had read and understood either of the dragon books that they would even try the task with RE? I don't. Once you put something like parsing and code generation in your personal toolbox, you would be surprised at the tasks before you that are a lot less intimidating.
I agree with Thomas about TAOCP. I'll give you a particular example. Volume 2, "Seminumerical algorithms" has a description of how to do long division. It turns out that we needed to do that when shipping a C compiler for 8086/80286 targets that didn't have an '87. And there is a reference to it in Coders at Work about that particular rare case that turns up only seldom.
Have you read the chapter on random number generation? How he made up this convoluted procedure to use one number to go to a page in a reference book to pick another number, and eventually ended up with a cycle of numbers that was disasterously small? It is fun.
And having an original edition and the recently issued boxed set, it is fun to see some of the problems change from HM 50 to something else. For example Fermats Last Theorem.
The lesson from that is repeated in people writing and using crypto. Just ask Tom.
While there are downsides to a university education, as often pointed out here on hacker news, the experience take you, if you are willing, to places that you wouldn't have on your own.
Similarly, the problem in front of you might not automatically make you run to get the dragon book or the others on the list, perhaps a friend can twist your arm to get you to read it.
You don't always know what you need ahead of time. There is a common word for that here, I think.
Did you ever see that stack overflow post which says in dozens of ways that you can't fully take apart (parse) HTML with regular expressions? If not, you should. It is informative and entertaining.
Don't you think that if those who attempt to separate HTML with regular expressions had read and understood either of the dragon books that they would even try the task with RE? I don't. Once you put something like parsing and code generation in your personal toolbox, you would be surprised at the tasks before you that are a lot less intimidating.
I agree with Thomas about TAOCP. I'll give you a particular example. Volume 2, "Seminumerical algorithms" has a description of how to do long division. It turns out that we needed to do that when shipping a C compiler for 8086/80286 targets that didn't have an '87. And there is a reference to it in Coders at Work about that particular rare case that turns up only seldom.
Have you read the chapter on random number generation? How he made up this convoluted procedure to use one number to go to a page in a reference book to pick another number, and eventually ended up with a cycle of numbers that was disasterously small? It is fun.
And having an original edition and the recently issued boxed set, it is fun to see some of the problems change from HM 50 to something else. For example Fermats Last Theorem.
The lesson from that is repeated in people writing and using crypto. Just ask Tom.
While there are downsides to a university education, as often pointed out here on hacker news, the experience take you, if you are willing, to places that you wouldn't have on your own.
Similarly, the problem in front of you might not automatically make you run to get the dragon book or the others on the list, perhaps a friend can twist your arm to get you to read it.
You don't always know what you need ahead of time. There is a common word for that here, I think.