That's pretty much what my copy does. I'm grateful the profession has TAOCP as a resource, but the reality for the majority of workaday engineers is that most of the sort of art described in that series is abstracted out into libraries. As fun or challenging as it might be to thinking about developing your own implementation of a fundamental algorithm or data structure, you're probably far better off reusing whatever you have available to you already in your environment. This has the tendency of pushing the work to the boundaries, where engineering is more about connecting existing pieces than anything else. (Which isn't a problem... I'd hate to live in a world where every home that's built requires the builder to cut down trees and process their own lumber, etc.)
I do least take solace in the fact that the contents of TAOCP are a lot less likely to get stale than the majority of tech books.
> That's pretty much what my copy does. I'm grateful the profession has TAOCP as a resource, but the reality for the majority of workaday engineers is that most of the sort of art described in that series is abstracted out into libraries.
The books are a collection of algorithms and commentary on them. That is not that different from a collection of algorithms in a library.
> you're probably far better off reusing whatever you have available to you already in your environment
I think even Knuth himself would agree here - but it’s also worth going through the implementation yourself once or twice (even if you just throw it away) until you really understand what it’s doing, so that you know what’s most useful when.
> but it’s also worth going through the implementation yourself once or twice (even if you just throw it away)
I tend to agree, but I'm not completely sure where I'd draw the line between things you have to implement to 'really understand' and things you can just use. ie: I've written hash tables over the years, but I've never written a persistent (think Clojure) style hash table. Maybe I should write one to really understand it? It sounds like fun, and I'd probably learn a lot, but I'm also not at all convinced it would help my effectiveness. The argument becomes even less convincing at larger scales and lower layers. (I don't need to implement a language runtime or SQL database to understand how to use one effectively. Even if, again, both of those sound like a lot of fun and a good way to learn some thing.)
If I had to come up with a general guideline, it would be to encourage developers to be mindful of what's around their layer of the stack and be prepared in the (very unlikely) event to work in one of those layers. But even that's kind of handwavey.
I do least take solace in the fact that the contents of TAOCP are a lot less likely to get stale than the majority of tech books.