Slashdot Mirror
Ask Slashdot: Have You Read 'The Art of Computer Programming'? (wikipedia.org)
In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming, publishing three volumes by 1973, with volume 4 arriving in 2005. (Volume 4A appeared in 2011, with new paperback fascicles planned for every two years, and fascicle 6, "Satisfiability," arriving last December). "You should definitely send me a resume if you can read the whole thing," Bill Gates once said, in a column where he described working through the book. "If somebody is so brash that they think they know everything, Knuth will help them understand that the world is deep and complicated."
But now long-time Slashdot reader Qbertino has a question: I've had The Art of Computer Programming on my book-buying list for just about two decades now and I'm still torn...about actually getting it. I sometimes believe I would mutate into some programming demi-god if I actually worked through this beast, but maybe I'm just fooling myself...
Have any of you worked through or with TAOCP or are you perhaps working through it? And is it worthwhile? I mean not just for bragging rights. And how long can it reasonably take? A few years?
Share your answers and experiences in the comments. Have you read The Art of Computer Programming?
But now long-time Slashdot reader Qbertino has a question: I've had The Art of Computer Programming on my book-buying list for just about two decades now and I'm still torn...about actually getting it. I sometimes believe I would mutate into some programming demi-god if I actually worked through this beast, but maybe I'm just fooling myself...
Have any of you worked through or with TAOCP or are you perhaps working through it? And is it worthwhile? I mean not just for bragging rights. And how long can it reasonably take? A few years?
Share your answers and experiences in the comments. Have you read The Art of Computer Programming?
It isn't terribly complex now that geniuses like Knuth have spent literally decades simplifying it for you, sure. Step deeper into the world and you'll be truly amazed at how deep it is ... and likely staggered that it works as well as it does.
"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
It's not complex if you merely want it to run, but if you want flexible, maintainable, and readable code, then it is complex.
Table-ized A.I.
It isn't terribly complex now that geniuses like Knuth have spent literally decades simplifying it for you, sure. Step deeper into the world and you'll be truly amazed at how deep it is ... and likely staggered that it works as well as it does.
+1. Programming isn't terribly complex if you always do it with your training wheels on, and if you never write anything that hasn't been written a hundred times before.
When all you have is a hammer, every problem starts to look like a thumb.
We should all chip in and get a complete set for the US Patent office. It might help them get rid of some bad patents they have issued over the years.
Or if you say you are using a computer in a patent app and don't cite Knuth as prior art for something you get tossed for that as well.
OP is being a bit flippant.
Conceptually, the idea of using alphanumberic characters to give computers instructions is "simple" and getting a computer to do basic operations is fairly simple with a good tutorial or guide.
The idea that the codebase for a web app like Yelp's website or a phone app like Snapchat is "simple" or "easy to learn" is of course patently ridiculous...I think it boils down to whether or not you give OP the benefit of the assumption.
Seriously OP really didn't say much other than, "No it is easy"
Thank you Dave Raggett
"Real programmers don't use PASCAL!" http://web.mit.edu/humor/Compu... I picture 110010001000 toggling the OS into the front panel while the rest of us have already bootstrapped the machine with kixtart a month ago. It's ok to stand on the shoulders of giants, but at the same time, it's good to look down and see how the foundation is you're standing on is really laid. There are times in my storied career where I have actually benefitted debugging c# or ruby code because I understood how parsing and execution worked. I have written better database queries in 4GL by knowing what was happening on the metal. So, before you get overly dismissive of knowing soup to nuts, I'd say that you should be aware that YES you can get by without it. But knowing the whole shebang, all the way down to the machine code, at least in broad strokes, DOES help you out occasionally, if not all the time.
Speak for yourself.
Since the safety checks are language dependent and aren't actually related to the algorithm logic, yes, that is better. This isn't a copy and paste recipe book. Learn the algorithm logic from the book then write your own implementation in the language of choice.
So you can't read them?
They are some of the most valuable books I'be ever owned. Whether during programming, developing FPGA logic or just trying to have a method of proving some of my algorithms. TAOCP is invaluable.
Computer science is still... well science and TAOCP is a cornerstone of computer science. You're confusing computer science and application programming.
There are certainly better places to learn the basics. Like for example, what is a red black tree? But TAOCP is where you understand them.
And I think his pseudo-computer concept was nifty. As for FORTRAN, all the fortran developers I know are generally slobs. They'd never touch these books.
This is so true. Knuth hasn't substantially updated his book to reflect modern thinking about his many subjects. It's encyclopedic, as in Encyclopedia Britannica, not as in Wikipedia. Pick a subject that you know something about, and Knuth still retains very old examples to fortify his analyses. There are many examples he gives in his book, where he doesn't give credit to the original designer of an algorithm. He tries to be historical in some parts, giving due credit to authors of algorithms, but not in other parts. His book is rambling, reflecting his thinking during the late '60s, and not well organized to clearly define a subject, step by step. That is where his successors surpassed him in writing useful reference books about algorithms. Indeed, his was the art of computer programming in 1968-1973. My recommendation: don't waste your time reading through the four to seven volumes of his "monograph", unless you're interested in the history of science. In all fairness, Donald E. Knuth has bitten off more than he can chew. That is why, in my opinion, he has failed to complete his oeuvre, and he is now in his late 70's.
It describes the very low level of a program and a computer.
No it doesn't. It describes the very low level of a program running on a computer from 30-50 years ago. The lessons that it teaches about algorithmic complexity are still valid, but the low-level stuff is not. Once you get to limits of the implementation, rather than of the algorithm, artefacts of caches in pipelines are far more important to performance. Not only will you not find, for example, Hopscotch Hash Tables in TAOCP, you also won't find an explanation of the underlying reasons for their performance.
I am TheRaven on Soylent News
I read most of volume 1. 30 years ago we were still working out basics and many programmer had to write or at least understand, basic processes. This is why this book was useful. In addition we were still writing lots of code, rather than just understanding and applying APIs. For instance no one is going to write a sort, or a gaussian elimination, or a GUI outside of classroom anymore. Few developers are going to have to know how to really code, or what is really happening in the engine they are using.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black