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?

Comments

Unfortunately no and I have a reason

[Anonymous Coward]

Unfortunately no and I have a reason:
Reading those books requires high degree of mathematical sophistication, particularly, knowledge of complex analysis, which I lack.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

Very little of TAOCP is original. Maybe Knuth deserves a bit of credit in implementing his ideas on an archaic pseudo-computer that he invented. TAOCP was far more useful to students before there was a field of Computer Science, when FORTRAN was the language of Mathematics, and UNIX was not yet born. Now his series is mainly of historic interest. Knuth has been surpassed, much as Albert Einstein has been in the field of Physics, and the Greeks have been in the areas of Philosophy, Logic, and Mathematics.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

So one should be a fully educated engineer or a half-way educated scientist to be able to benefit from it completely?

Re:Unfortunately no and I have a reason

[lgw]

Reading those books requires high degree of mathematical sophistication, particularly, knowledge of complex analysis, which I lack.

They're just algorithms textbooks. They're hard to read because of when they were written, and the accompanying style. More like pseudo-assembly than high-level pseudo-code.

But, hey, if you want to optimize your search algorithm that uses tape as storage, to take advantage of the new-fangled tape drives that can write backwards as well as forwards, it's the book for you! (Yes, that was really a thing, and an algorithm you'll find in Volume 3: Sorting and Searching.)

Personally, I don't think he does a great job explaining algorithms. I once needed to look up O(n) median for something, tried to understand it from Knuth, gave up on the cryptic text, and understood it right away from CLR (now CLRS). It is an exhaustive catalog, but it's not a great learning tool.

Re:Unfortunately no and I have a reason

[TechyImmigrant]

>CLR (now CLRS)

???

Common Language Runtime?
Calcium, Lime & Rust?

Re:Unfortunately no and I have a reason

[Anonymous Coward]

https://en.wikipedia.org/wiki/Introduction_to_Algorithms

Re: Unfortunately no and I have a reason

[aglider]

The little amount of maths that's in there is not that difficult to understand. And if you skipped it, you would be still learning a lot. Not reading taocp because of maths is just an excuse.

Re:Unfortunately no and I have a reason

[lgw]

The "R" is Rivest, who invented the algorithm for O(n) median, and some other stuff.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

The "R" is Rivest, who invented the algorithm for O(n) median, and some other stuff.

So as a 10 year old people don't expect you to have liners in your pocket. Well, I use liners for discharge, so I carry them to school. At the end of recess, I had 3 liners in my pocket. Now my best friend knew I had them, so she asked for one. Of course I gave her one. I casually tried to pull it out of my jacket pocket. Our class is in two lines, and my crush is in the line next to me. I gradually pulled the liner out to give to my friend. OOPS, she drops it. She tells me I dropped something, and I feel my stomach flop. I look at the gravel and see a bright pink carefree liner in the middle of the two lines. With some snicggering, and some staring, I pick of the liner saying it was just paper. Ben, who was in the next line, was laughing like crazy. My mind racing, I just shrugged it off. Later, my friend, Jadine, said, "You dropped your pad." I laughed with her. I actually didn't care that much anymore. I thought it was funny. Later, my best friend walked up to me at lunch telling me she dropped it on purpose because she thought it was funny, and that's what killed me. I'm still pretty mad, but I'll live.

One time I had to go buy tampons in a hurry at the store. Of course the ones I buy were out of my reach. There was nobody around other than a guy reading a magazine and a guy walking by so I had to do it. I asked the guy walking by, "Would you feel really awkward reaching for the pack of tampons up there? The ones I use just happen to be out of my reach." He had no problem grabbing them for me and we all had our little laugh and went on with our evening.. Hehe!

Re:Unfortunately no and I have a reason

[ShanghaiBill]

Personally, I don't think he does a great job explaining algorithms .... It is an exhaustive catalog, but it's not a great learning tool.

I agree with all of the above. There are better books. But criticizing TAOCP is like saying the emperor has no clothes. The series is difficult to understand, and everyone thinks it is their own fault for not being smart enough, rather than that the books actually aren't very good.

Disclaimer: I own the entire series, and keep them in my office to impress people, but I haven't actually opened them in the last 20 years.
Additional Disclaimer: I loved Don's "Concrete Mathematics" book ... for the humor as well as the math. I keep it in my office to impress people too.

Re:Unfortunately no and I have a reason

[bzipitidoo]

CLR is Introduction to Algorithms by Cormen, Leiserson and Rivest. The S in CLRS is for Stein, who joined the team for the 2nd edition. When CLR came out in 1990, it was hailed as the best algorithms textbook ever, and what an algorithms textbook should be, a huge jump in readability and clarity over the not wholly satisfying existing algorithms textbooks. It uses pseudocode, instead of a real programming language. Allowed the algorithms to be presented cleanly, without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input. Don't have to declare any variables, or figure out how many elements an array needs.

The Abelson and Sussman textbook, Structure and Interpretation of Computer Programs, uses LISP (actually Scheme). There are quite a few LISP fanatics who passionately feel it is still the best programming language made, citing such reasons as the simplicity of writing an interpreter for it. However, that textbook is pretty difficult. The authors didn't appreciate how hard recursion can be for many students to understand, and LISP and functional programming in general uses recursion so heavily it's the proverbial hammer for every nail of a programming problem.

Since then, programming languages have improved. Still not good enough for the textbook, but closer.

Re:Unfortunately no and I have a reason

[passionplay]

presented .... without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input.

Wait - did I read that correctly? "without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input" = improved textbook?

Aren't these the attack vectors used by malware and viruses today?

I think I'm lost. We use a newer shiny shiny that shows us to do something without showing it done safely and it's better because people will magically include the necessary safety checks and our new algorithms are better because they are clearly implemented without the safety checks.

That's the premise of this statement and the assessment?

Just making sure I'm on the same page.

Re:Unfortunately no and I have a reason

[shaitand]

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.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

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.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

Despite The Borg's recommendation to read them, I did anyway.
Much of it was very deep math, but some of it stuck and was helpful.

I didn't realize he was 24 when he started writing; amazing guy.

That and the Steven's network books were early software Bibles...
Still have them in my book collection.

CAP === 'overhang'

Re: Unfortunately no and I have a reason

[Anonymous Coward]

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.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

Security doesn't permeate through every context: In the context of effectively and simply communicating an algorithm, the language specific details and compiler concerns are fluff that detracts from the concept being conveyed. Once you have that concept in your head it is the job of the programmer to correctly fashion it with consideration for language and context in the code (the combinations of which you could never adequately cover in a text book anyway).

Re:Unfortunately no and I have a reason

[Anonymous Coward]

Yes, all four of them, and they taught me "everything". This was way before I even knew there was such a thing as C, or compilers, but painstakingly implemented most algorithms from their descriptions and examples, in MC68000 asm.. For me, they forever stay in my bookshelf.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

search algorithm that uses tape as storage, to take advantage of the new-fangled tape drives

Such co-location issues are actually still very relevant if you consider cache optimisation, or even GPU implementations of algorithms.

Re:Unfortunately no and I have a reason

[Drethon]

Reading those books requires high degree of mathematical sophistication, particularly, knowledge of complex analysis, which I lack.

They're just algorithms textbooks. They're hard to read because of when they were written, and the accompanying style. More like pseudo-assembly than high-level pseudo-code.

I'm taking an algorithm design class and despite acing the programming side of it, still have a fit trying to translate the formulas they like to write them in. It is probably great short hand for people well versed in mathematical notation, I've just never gotten a handle on it.

Re:Unfortunately no and I have a reason

[Bright Apollo]

You have a reason, it's just not a good one.

In 1994 "Concrete Mathematics" came out by Knuth, to assist mathematically-challenged readers of TAOCP. You've had 22 years to read and understand that book, in order to read and understand TAOCP

Put another way: if you haven't decomposed your problem with tackling TAOCP into manageable tasks, programming may not be for you.

--#

Re: Unfortunately no and I have a reason

[RabidReindeer]

I can't say I've ever read Knuth in the literary sense. It's more of the ultimate reference.

Thankfully, I no longer have to construct sorts, searches, random number generators, etc. every time I write a program, since modern-day language systems come pre-supplied. However, someone has to implement those pre-supplied algorithms, and that someone almost certainly referenced Knuth. He has provided a concise, well-explained collection of analyses, discussions and sample implementations of many of the most important functions needed by almost everyone in the software development field.

The downside of it is MIX. I understand the reason Knuth created MIX, but MIX is an assembly language and not even a commonly-used one (and intentionally so). I know that there are many who think that the purpose of computers is to run machine (assembly) language, but they're wrong.

The purpose of computers is to run software. How it runs the software is secondary. You can see this in the fact that some machines include in their instruction set specialized functions related to specific abstract features. The Prime Computer instruction set had machine-language implementations of the FORTRAN 3-way branch. I think it was Honeywell that had an OS task dispatcher function implemented as a machine-language instruction. The Inter iAPX432 was designed to run Ada, the IBM System/360 had the Translate instructions, and the IBM zSeries has a major subset of the Unix stdlib implemented as CISC instructions, including a few of the Knuth algorithms.

Keeping software as a set of bits corresponding to primitive functions is convenient for implementing von Neumann machines, but it should be realized that it's the means and not the end, and when scaled, tends to lose the abstract picture in the minutae. If minutae were the end of it, one should be programming microcode and manually switching gates - on many machines, the "machine language" is itself an abstraction interpreted via microcode.

I've often complained that one of the biggest annoyances in IT is that you can pop out a prototype GUI in a day or 2 and everybody thinks it should go to full production next Thursday, where no one in their right mind would ever expect a scale cardboard model of a building or bridge to be ready for use in such time.
But there's a similar break in education in that in most cases CIS courses use a "practical" language instead of an abstract one.

While assembly language was very common when Knuth wrote Volumes I-III, he was aware that there was no universal high-level language any more that there was a universal low-level one, which was another reason he invented MIX. Even academically-inclined languages such as Modula ultimately detoured into practical use, warping their abstraction. And, although ideological purity makes me projectile-vomit, when you're dealing with abstract concepts, I prefer to keep things truly abstract. Otherwise it warps one's approach to later solutions.

Djisktra did. in fact attempt an abstract high-level language in his "A Discipline of Programming", although it has some odd warts of its own. Personally, I'd vote for Ada, because while the last time I actually ran Ada, it nearly burned out the bearings on a mid-line IBM mainframe, it is the only common language I know where values and functions are assigned ranges and domains - an essential concept that is taught at the very beginning of differential calculus classes, but not nearly well-stressed enough in most CIS curricula. Were it otherwise, perhaps fewer satellites would have been destroyer.

Ada, incidentally, is part of the gcc/gnat toolset available on almost any Linux development system and modern-day PCs are considerably more powerful than a 1990 mid-level IBM mainframe (but then again, probably so are most cellphones), so anyone who's curious can explore.

Re:Unfortunately no and I have a reason

[luis_a_espinal]

presented .... without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input.

Wait - did I read that correctly? "without any boilerplate code, overhead, or worries about limitations, no need for tedious checks for array out of bounds, numeric overflow, or out of memory, or invalid input" = improved textbook? Aren't these the attack vectors used by malware and viruses today?

Everything you mentioned are supposed to be a given. A person who needs explicit indication of them are not at the level required to use a book like CLRS. I don't mean it as an insult, but as an observation.

Moreover, many of the checks you mention are handled by constructs and idioms that are language dependent. For example, boundary checking in C will be different from, say, Ada or Java, let alone something like Ruby or LISP.

Also, when you are stuying algorithms at that level, you are assumed to have a certain maturity that makes reference to such things irrelevant. Think of it like this: If you are learning how to solve quadratic equations, you do not need a lesson in adding fractions, do you?

Same principle applies here. When you are taking a book like CLRS, it is to study the mathematical properties of algorithms.

I would say that a there is a more hands-on book that directly addresses these concerns: O'Reilly's Algorithms in a Nutshell. This is a really nice pocket book.

Re:Unfortunately no and I have a reason

[freudigst]

lgw is the cryptic pot calling the kettle black in this case.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

Yes that is correct douchebag. Can't believe how dumb you are...

Re: Unfortunately no and I have a reason

[Anonymous Coward]

Good stuff! Was thinking about office decoration lately!

Was thinking about a few Dev Opps and Agile classics, but I think you're spot on. Nothing better than stuff people can't understand.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

But, hey, if you want to optimize your search algorithm that uses tape as storage, to take advantage of the new-fangled tape drives that can write backwards as well as forwards, it's the book for you! (Yes, that was really a thing, and an algorithm you'll find in Volume 3: Sorting and Searching.)

This is a limited view of "tape". MapR HDFS uses "append-only" file system:

* https://www.mapr.com/blog/append-only-file-systems-vs-read-write-file-systems-whiteboard-walkthrough
* https://www.quora.com/Is-HDFS-an-append-only-file-system-Then-how-do-people-modify-the-files-stored-on-HDFS

ZFS (along with others) uses an "append-first" type of delayed allocation for its copy-on-write properties:

* https://en.wikipedia.org/wiki/File_system_fragmentation#Mitigation
* https://en.wikipedia.org/wiki/Copy-on-write

It then goes back and clears up blocks that are no longer needed (i.e., not preserved in snapshots). It can also be used in virtual memory and garbage collection, as going back and forth can thrash the cache, so if you only go "forward" then it's more likely for caches to be primed and you don't suffer the performance penalty of a miss. Perhaps also true for SIMD operations as you're mostly going "forward" and some pre-sorting can perhaps help things along.

The principles can be used in other places besides "tape".

Re: Unfortunately no and I have a reason

[Marxist Hacker 42]

This needs to be in a blog. Especially the point of people seeing a very rough prototype GUI and wanting a full production system by next Thurdsay.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

if you want to optimize your search algorithm that uses tape as storage, to take advantage of the new-fangled tape drives that can write backwards as well as forwards, it's the book for you! (Yes, that was really a thing, and an algorithm you'll find in Volume 3: Sorting and Searching.)

Todays problem could benefit from this kind of algorithms. Many of the old COBOL technics which read data on tape, with low memory footprint, are used for Big Data treatments and works pretty well.

Re:Unfortunately no and I have a reason

[UnknownSoldier]

> More like pseudo-assembly than high-level pseudo-code.

It is actually worse then that. You learn some bullshit imaginary assembly language MMIX, instead of a pragmatic real assembly language like 6502, x86, or ARM which you could have immediately tried out. And while an assembler and debugger exist for MMIX this is yet more time you need to waste on some obscure, niche, proprietary language and toolchain.

That said, what The Art of Computer Programming lacks in quality it makes up in quantity.

> and understood it right away from CLR

100% agree that Introduction to Algorithms is a fantastic book! It definitely is on the "short list" of every books a computer programmer should own.

Re: Unfortunately no and I have a reason

[ClickOnThis]

As for FORTRAN, all the fortran developers I know are generally slobs. They'd never touch these books.

Former FORTRAN programmer here. I hope I am a living example of how it is possible to enlighten FORTRAN programmers ... by teaching them to program in some other language. Almost any post-FORTRAN language can help, but those in the C-family are an excellent starting-point.

The most important criterion for choosing a language to solve a problem is its expressive power in the problem-domain. When you show a FORTRAN programmer just how much easier their problem can be to solve in another language, you're on the path to converting them.

That said, FORTRAN has grudgingly evolved over the decades. But it has always been behind other languages.

Re:Unfortunately no and I have a reason

[angel'o'sphere]

Aren't these the attack vectors used by malware and viruses today?
Yes and no.

And what exactly does that have to do with algorithms?

Security, Attack Vectors, Bounds Checking, Input Sanitation: that all has nothing to do with algorithms. Hence for anyone it is easier to buy 5 books:
One for algorithms
One for security
One for Attack Vectors
One for Bounds Checking (while that might touch algorithms, see "sentinel based algorithms")
Input Sanitation

And if you are up for it, you probably might buy several books for each topic. Keeping books on topic is one of the most important things you might learn in "programming" anyway: separation of concerns.

Re:Unfortunately no and I have a reason

[Anonymous Coward]

'supposed to be" ???

clearly you haven't been paying attention. All the attack vectors we currently have in code are because of the lack of coders, er, uh, sorry, I know you prefer the term 'developers' these days, don't do any-damn-thing about doing inputs testing or overflow, invalid input, etc.

So, don't climb on your high horse and lecture about how the 'best textbook' doesn't teach a damn thing about them, when that led to the code we now have to try to make secure.

So, also, if all that is, "... a given...", then why is none of it done reliably????

Re: Unfortunately no and I have a reason

[computational super]

The little amount of maths that's in there is not that difficult to understand.

What? Holy shit, what books are you talking about? Definitely not TAOCP. The first half of Volume 1 is all math - specifically discrete math: the kind that's relevant to analysis of computer algorithms, but that's not studied in much detail outside of computer science. I have a master's degree in CS and consider myself pretty competent when it comes to, say, calculus, but I got lost in some of the sections on harmonic series and generating functions.

Volume 2 is _all_ math and again, not trivial math. There's 30 pages of theoretical discussion on what makes an infinite sequence random. The introduction to chapter 4 talks about number representation in base -10. There's a _LOT_ of math, and it's very difficult to understand (but it is fun to do so).

Re:Unfortunately no and I have a reason

[CAOgdin]

You need the flexibility of mind that comes from learning more languages. In the computer field I've written code in over 50; all I have to figure out at the start is which objects this language uses...the rest is easy; there are only sequence, alternation and iteration at the root of them all. It's the implied attributes of the various data structures that can be created, and the linguistic elements that refer to them that makes one language different from another. Compare Windows CMD with PowerShell, to see what I mean.

On the other hand, in the realm of natural languages I have command of one, and remanents of the Japanese I learned living there in the late 1950s.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

You make it sound like this book made him old :)

Re:Unfortunately no and I have a reason

[CAOgdin]

That may be your way, but it's a dead-end. That "pseudo-language" is a prototype of most high-level programming languages, and limiting your self to your sole preferred language is like speaking only English and then trying to work in a foreign country...a fish out of water.

Re: Unfortunately no and I have a reason

[CAOgdin]

Elegantly put by someone who's clearly a life-long learner.

A well spoken contrast to many of the monolingual posting here.

Re:Unfortunately no and I have a reason

[Drethon]

I constantly switch between the major C languages (not a major feat), C, C++, Java, C# and my resume has Visual Basic, Ada, Python, Perl, Assembly, FORTRAN, Lab Windows, digital hardware design and a few others I can't remember. I just never got a good handle on the mathematical notation used in algorithms, probably because I only used in in classes, pretty much all my jobs use natural language requirements.

Re:Unfortunately no and I have a reason

[hackwrench]

https://www.bing.com/search?q=...

Re:Unfortunately no and I have a reason

[hey!]

The Abelson and Sussman textbook, Structure and Interpretation of Computer Programs, uses LISP (actually Scheme). There are quite a few LISP fanatics who passionately feel it is still the best programming language made, citing such reasons as the simplicity of writing an interpreter for it. However, that textbook is pretty difficult. The authors didn't appreciate how hard recursion can be for many students to understand, and LISP and functional programming in general uses recursion so heavily it's the proverbial hammer for every nail of a programming problem.

Well, that's what you get when you beta test your textbook with MIT students. But that said, CLRS is no picnic for people who aren't very good at math, either.

Re:Unfortunately no and I have a reason

[pthisis]

I constantly switch between the major C languages (not a major feat), C, C++, Java, C# and my resume has Visual Basic, Ada, Python, Perl, Assembly, FORTRAN, Lab Windows

A lot of these languages are kind of samey-samey; the mind expansion he's talking about comes from working in languages that use very different programming models that make you approach problem-solving in new ways. Try adding, say, Haskell (or SML or ELM), Forth, and Prolog to the list, for starters.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

I don't think he was advocating to learn one language. I think he meant that why use such an obscure language when he could have used others that were in use and more popular around the time. This way, it's not such a big jump to using the info in the book in real life.

Re: Unfortunately no and I have a reason

[GoblinKing]

I have to second you on the choice of Ada. A most robust and controlled/secure development platform for general purpose use, I have been developing in Ada for as long as I have owned TAOCP (got my copy in the early 80's). Every one of the exercises were implementable in Ada.

As for reading the books ... I've read through them over a dozen times in the past 30+ years ... can't say I completely understand all of it but my comprehension grows every year. :D

Re:Unfortunately no and I have a reason

[Drethon]

Noted for consideration, thanks!

Re: Unfortunately no and I have a reason

[aglider]

Then you need to go back to school! :-)
I had very little troubles in following that stuff.

Re: Unfortunately no and I have a reason

[Anonymous Coward]

Is there a specific reason you chose 4 examples of assembly languages that were all invented AFTER Knuth wrote and published his works?

The answer is that any arbitrary language available at the time would be useless to a great many readers. Had Knuth used some particular extant instruction set, his books would have become known as "algorithms for the IBM/360" by everyone on the street. The choice of a language that was, practically speaking, useless for everyone, was a good one: it made it clear that these were universal algorithms that weren't intended to be "tricks for the /360" or whatever.

Re: Unfortunately no and I have a reason

[ShanghaiBill]

Nothing better than stuff people can't understand.

Yes, the best office book is one that nobody ever wants to borrow.

Here is another office tip: Put red caps on all your pens. Nobody steals red pens.

Re:Unfortunately no and I have a reason

[ezdiy]

Na. Start with TAOCP, then read the harder books (SICP, CLRS).

I can't read math for shit either, and it's not really that necessary for the verbose style of knuth. So one can do just fine with just pseudocode.

Why SICP later? It is a bit harder to read than TAOCP, as it is not really a bag of ready to use tricks anymore - it challenges the reader to think about (functional) programming at a more fundamental level (and you don't need to know much about "math" either, it's an intro course book).

Re:Unfortunately no and I have a reason

[TechyImmigrant]

Ah. OK. I've seen that book before. It's not as comprehensive as TAOCP, but is a better tutorial for people learning algorithmic theory.

Re: Unfortunately no and I have a reason

[UnknownSoldier]

Yes, he should go back and update his book with _actual_, popular, assembly languages. Using _practical_ languages means a student doesn't learn some obscure language that no one gives a fuck about but can _apply_ their skills immediately.

Also, by learning _multiple_ assembly languages the student doesn't pigeon-holed into myopic thinking. By being exposed to multiple languages they see how different design and implementation trade-offs were made.

The day of professors inventing yet-another-language are over. You can teach Theory AND Application, not just "my pet theory".

Re: Unfortunately no and I have a reason

[Anonymous Coward]

This is just silly. You don't know what you are talking about. This has nothing to do with assembler or its popularity back when the books were written. TAOCP is not your mommy's cookbook. It is about analysis of algorithms -- precise to the point of having no alternative to using an instruction-level model of a computer. No high-level language or pseudo-code could possibly provide means for such analysis. Now stop speaking nonsense and go back to re-reading your favorite comic, boy.

Re: Unfortunately no and I have a reason

[Ed Avis]

See what Joel Spolsky wrote:

If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

Re: Unfortunately no and I have a reason

[Ed Avis]

It reminds me of Anthony Burgess's novel A Clockwork Orange. He realized that any real-world slang would soon become out of date so he invented his own slang language, Nadsat, for the characters to speak. Of course, this can be taken too far, where the made-up language comes to dominate the work with the story being an afterthought. Like some of JRR Tokien's works, for example. In fact you could say that TAOCP is the LOTR of computer science.

Re: Unfortunately no and I have a reason

[UnknownSoldier]

Ha! That's a pretty good analogy -- except for one minor thing: LOTR isn't as dry and boring as TAOCP. :-)

Re:Unfortunately no and I have a reason

[bzipitidoo]

How about a car analogy? Algorithms is like engine and transmission design. That the driver can easily drive the car over a cliff or into a wall, that driving takes considerable skill and constant attention to keep the car on the road, is not the concern of the motor designers, nor should it be.

About as far as engine design can go to enhance safety, apart from ensuring that the engine doesn't blow up or make an oil slick on the highway and cause an accident, is stuff like limiting the maximum output, and therefore speed, and add means for mechanical and computerized control that can be used by safety features, but need not be.

Re:Unfortunately no and I have a reason

[bzipitidoo]

CLRS is no picnic for people who aren't very good at math

That's true. The first chapters wade into big O notation, in ways that don't match the standards of clarity of the rest of the book. You shouldn't need calculus to understand big O. It's good to show how to apply calculus to these problems, and calculus is a natural fit for the necessary math, but the student shouldn't be pushed into a refresher course in calculus to comprehend the basic concepts. The authors try to fill in some of the mathematical knowledge they apply in the next sections, rather than restrict themselves to basic algebra.

Re: Unfortunately no and I have a reason

[Marxist Hacker 42]

Thank you, this is just what I was looking for.

Hell no

[110010001000]

Programming isn't terribly complex. If you want to program, just do it.

Re:Hell no

[UID30]

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.

Re:Hell no

[Travco]

Driving a car isn't hard millions do it. But how many drive in NASCAR?

Re:Hell no

[110010001000]

Nah, I've been programming longer than Knuth has, starting with machine language. You just need to think procedurally.

Re:Hell no

[Tablizer]

Programming isn't terribly complex. If you want to program, just do it.

It's not complex if you merely want it to run, but if you want flexible, maintainable, and readable code, then it is complex.

Re:Hell no

[110010001000]

Tens of thousands. How many people have walked on the moon wearing blue underwear? I can ask irrelevant questions too.

Re:Hell no

[110010001000]

Nah, not really. It just requires logical thought.

Re:Hell no

[Anonymous Coward]

Many people can learn to program in well developed environments with sophisticated debugging tools, rich base classes, and optimized compilers.

Most people cannot program without those tools, and they know very little about machine language and how the computer or OS they are targeting actually works under the hood.

So saying programming isn't terribly complex just doesn't mean very much without some context.

Re:Hell no

[110010001000]

Nah, sure they can. It isn't terribly complex. Even kids can program to some degree.

Re:Hell no

[Tough Love]

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.

Re:Hell no

[110010001000]

Nah, it has never been terribly complex. Even before we had compiled languages it wasn't terribly complex.

Re:Hell no

[Tough Love]

Nah, I've been programming longer than Knuth has, starting with machine language. You just need to think procedurally.

In your case, it sounds more like "sporadically".

Re:Hell no

[110010001000]

Nah, not really. It might be hard for you, but you might be a muddled thinker.

Re: Hell no

[Anonymous Coward]

I don't know when Knuth started (prob before me) but I started in '71 am still doing it professionally. I've read other classics but only skimmed small bits of his work. Lots out there to learn, particularly in niche programming.

Re:Hell no

[Anonymous Coward]

I can program in 6502, Z80, x86 and 680x0 assembly languages. Knuth doesn't deserve any thanks.

Re:Hell no

[Falos]

Nah, it's easy if you're as smart as I am.

Re: Hell no

[Anonymous Coward]

Hmm. Have you taken Numerical Analysis?

Re:Hell no

[Anonymous Coward]

...reading through thread: you really like the word nah as a sentence opener, don't you?

Re:Hell no

[__aaclcg7560]

Driving a car isn't hard millions do it.

I've waited until I was 37-years-old to learn how to drive. My father wasn't going to teach me as a teenager to drive stick on his one-ton flatbed that he put a million miles on in ten years. Since Silicon Valley has a well-developed transit system, I got around just fine without having a need for a vehicle. One day my father abandoned his old car in my carport. I had not choice but to get my driver license and take possession of the car. Took me three years to find out about all the repairs that he didn't tell me about. It's easier to own a car when you're more mature and financially responsible, especially if your father is DIYer who doesn't believe in mechanics.

Re:Hell no

[0100010001010011]

110010001000 caught at work

Re:Hell no

[Anonymous Coward]

That's why you're a garbage programmer Larry...that and you're on Slashdot all the time.

Seriously, if you don't step it up, we're going to have to let you go.

-Your boss, who knows what sites you go to

Re:Hell no

[Anonymous Coward]

How long have you been working at Microsoft?

Re: Hell no

[Tough Love]

Hmm. Have you taken Numerical Analysis?

It's quite clear that he (she, it?) has never studied computer science at all.

Re: Hell no

[AcerbusNoir]

It's that kind of mentality that has given birth to a plethora of buggy, unmaintainable code that's ridden with security holes.

Re:Hell no

[hideki.adam]

I can program in Z80 and 6502 assembly,

Rodnay Zaks deserves a great deal of thanks -.o;

Re: Hell no

[Anonymous Coward]

They're completely correct.
Programming in itself is not very hard. Anyone can do it. Though only a few will be interested enough to keep doing it long enough to get good at it.
You can try to make yourself feel superior by pretending it's some sort of holy art. But it's not, it's really not.
Certain things you may want to _do with it_ might be hard, but that doesn't make it hard.

Winning a rally is hard. Winning a rally requires driving, but it doesn't follow that driving is hard. If you think that the fact that solving a particular class of problems via programming is hard that therefore programming is in itself hard then either 1. You haven't been programming very long, or 2. You really _shouldn't_ be programming. Or 3. Both.

Programming being easy doesn't mean that books like TAOCP aren't worthwhile - they definitely are. Because something can be pretty easy, but still have plenty of scope for you to learn and improve, and find better techniques.

Re:Hell no

[Pseudonym]

I've been programming longer than Knuth has, starting with machine language.

If it's not a rude question, how old are you, exactly?

Re:Hell no

[jgullstr]

Well, you have to start somewhere. Why not by reading TAOCP? Can't be terribly complex.

Re:Hell no

[antdude]

Is that you Nike/Shia? :P

Re: Hell no

[Anonymous Coward]

Writing is easy. Lots of people do it. Writing a Ph.D. dissertation is hard. Because details.

Re: Hell no

[Marillion]

“Computer Science is no more about computers than astronomy is about telescopes.” - commonly attributed to Edsger Dijkstra, but disputed.

I have sometimes compared those who have studied computer science (as opposed to learning how to program) with those who have studied music. You can be a very successful programmer without any computer science just as you can be a very successful musician without music theory. Mastery of the advanced studies of your discipline will make you a better than merely someone who can just get the job done.

Re: Hell no

[Anonymous Coward]

Old enough to lie, I think.

Re:Hell no

[Anonymous Coward]

Step deeper into the world and you'll be truly amazed at how deep it is

Step deeper and it turns out to be deeper?
Wow, you're so deep.

Re:Hell no

[Anonymous Coward]

wuut? complex is the opposite of the virtues you espouse.

Re:Hell no

[Bing Tsher E]

But can you program in Z80 and 6502 machine code? You really only need to know a few instructions, because the details are in the bits.

Re:Hell no

[FyRE666]

Wish I had mod points.

Re:Hell no

[Anonymous Coward]

Programming isn't terribly complex. If you want to program, just do it.

And people wonder why software is full of bugs and their devices crash or have hiccups.

Re:Hell no

[hcs_$reboot]

Not mentioning efficient algorithms.

Re:Hell no

[Anonymous Coward]

yea, we have found the PHP developer!

Re:Hell no

[Glock27]

Programming isn't terribly complex.

Awesome that you think so! Now, program some realtime flight surface control software for a fly-by-wire jet and sleep well knowing that your program will never, ever, kill anyone... (Or, substitute any other safety critical software you can think of - and theres a lot!)

"Programming" (by which I really mean software engineering) is one of the most complex activities in existence...

Re:Hell no

[aldousd666]

"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.

Re: Hell no

[silanea]

“Computer Science is no more about computers than astronomy is about telescopes.” - commonly attributed to Edsger Dijkstra, but disputed.

[...] Mastery of the advanced studies of your discipline will make you a better than merely someone who can just get the job done.

The caveat being here that a good portion of what goes for CS at universities is essentially "How to use the vast resources of a supercluster as a glorified pocket calculator". I had the dubious honour of suffering through four semesters of so-called CS at my uni, and I can attest that you can be an incredible computer scientist and still be unable to program even modestly simple applications. And that is said without even touching upon the vast difference between CS and software engineering (and the equally vast difference between software engineering and programming, to be fair).

All three disciplines have their place. But CS is not exactly the 'advanced study' of programming.

Re:Hell no

[TechyImmigrant]

I can program in 6502, Z80, x86 and 680x0 assembly languages. Knuth doesn't deserve any thanks.

Me too. Rodney Zaks gets my thanks.

I use TAOCP as a handy authoritative reference for algorithms in specs. It's not a great read though.

Re:Hell no

[TechyImmigrant]

But can you program in Z80 and 6502 machine code? You really only need to know a few instructions, because the details are in the bits.

I wrote my own assembler and debugger for programming my Apple //e. I got fed up of typing in hex.

https://github.com/dj-on-githu...

Re:Hell no

[TechyImmigrant]

>rich base classes

are complex.

Machine code is simple. There's much less to know,

Re:Hell no

[tsa]

NASCAR is easier than, say, driving in Amsterdam. In Amsterdam you find bikes and pedestrians on your path, and, Oh! The horror! Right turns!

Re:Hell no

[goose-incarnated]

Programming isn't terribly complex.

Awesome that you think so! Now, program some realtime flight surface control software for a fly-by-wire jet and sleep well knowing that your program will never, ever, kill anyone... (Or, substitute any other safety critical software you can think of - and theres a lot!)

"Programming" (by which I really mean software engineering) is one of the most complex activities in existence...

Just because it can be doesn't mean that it always is. The avionics-software programmer is working very differently to the muh-first-website programmer. It can be complex like avionics, but it can also be simple like javascript text-adventures.

"Programming" can be, at times, one of the most complex activities in existence. It can also be, at other times, one of the simplest activities you can find paying high salaries. Lets not pretend that programming is always more complex than brain surgery. It can (on rare occasions) be, but it's usually not much more complex than arithmetic.

Re: Hell no

[Anonymous Coward]

CS is not exactly the 'advanced study' of programming.

I can attest that you can be an incredible computer scientist and still be unable to program even modestly simple applications.

Do you see the connection here? CS is not a degree in programming and it should not be a degree in programming. I don't expect a trained CS to be a good programmer. I do expect one to be a good mathematician. I expect one to model information requirements and computational systems as mathematical objects and then be able to formally prove certain properties about it.

Re: Hell no

[Anonymous Coward]

Mastery of the advanced studies of your discipline will make you a better than merely someone who can just get the job done.

OK, genius. Perhaps mastery of the English language would make you a better.

Re: Hell no

[Anonymous Coward]

Creative writing requires creativity. Programming does not. Once upon a time if you came up with a brilliant idea you would have to code it yourself and that gave rise to the cherished myth of the computer genius, but thankfully we moved on from those primitive times. Now there are designers, who are creative, and programmers, who are code monkeys.

Re:Hell no

[SeriousTube]

That's not a name I see often! That's how I learned assembly too. "Programming the Z80".

Re: Hell no

[Anonymous Coward]

Bullshit. Surgery is complex. Aerospace engineering is complex. Programming is not. You deal with a controlled environment and you can backstep at any time. If you can't, it's your fault. Cooking is far more complex. There are good reasons why programmers are being replaced by low-wage workers while chefs are not.

Re:Hell no

[gweihir]

Hahahaha, funny! Sorry, do not have mod-points, but this is sarcasm done extremely well!

Re:Hell no

[passionplay]

Every program written today is in way shape or form another program from an earlier age with one more level indirection. There is a saying in the K&R world, that there is no problem that cannot be further simplified than with one more level of indirection. The difference today is that we no longer want to choose that level of indirection. We want to have it given to us. What was once syntactic sugar has become semantic necessity through reward for the deeper understanding of the subject. Being faster to market wins over being better.

Re: Hell no

[passionplay]

"Because " is not a complete thought. Could you please expound for those of us that don't think a noun covers the gamut of possibilities that you wish to cover? Since we are all geeks here, it stands to reason that the universe of the set covered by "details" is larger than your intent and indicating that your intent is universal assumes we have the same level of understanding as you.

"Because <noun>" is catchy in journalism because "for news - it shows an all encompassing view to attract audiences." (See what I did there?)

I for one would like to know what details you mean. Please and thank you.

Re: Hell no

[passionplay]

I took CS. I was required to program algorithms and do proofs in a multitude of languages. And none of the languages used were taught. The basis was trial by fire. Computer scientists were supposed to be able to learn any language at any time in order to solve the problem at hand. We learned to be language agnostic and pick up the language required every 2 weeks. It worked.

Re:Hell no

[serviscope_minor]

Nah, not really. It just requires logical thought.

Seems unlikely you'd find it as easy as you claim then!

Re: Hell no

[Anonymous Coward]

good reasons why programmers are being replaced by low-wage workers while chefs are not.

Yup. Because you can't outsource a chef to the lowest salaried third world country just to save a few bucks.

Believe me, with the razor thin margins in the restaurant industry most bosses would outsource to the third world if they could. To hell with the food quality, everyone else outsourced too!

Re:Hell no

[Anonymous Coward]

That's mostly true. In C, C++ (probably others), you used to build your structures knowing how the
processor would access them from what the compiler produced. Now, the compiler can re-order your
structure, put parts of it in its register set, and so on (depending on how the struct is used). So, it is
helpful to understand the low level stuff; I've come to trust compilers to do as good, if not better of a
job than I can arranging those items for optimum performance.

CAL === 'unaided'

Re: Hell no

[Bongo]

I imagine that's something like how constructing buildings (architecture) relies on engineering, and often it helps to know why a column has to be where it is, and what other possibilities there may be, to support the floor in some other way, but most of what the architect does is actually planning the layouts and elevations and how the building relates to the site and the people and their activities.

So I would imagine that a lot of the "discipline" in large projects isn't so much about pure engineering, it is often more about organising parts into systems which can be developed over time.

Like how the architect knows that where they put the hotel restaurant is going to affect where the kitchen goes and therefore where the store room goes and hence where the service entrance will likely be, and that you don't want to end up having to tear up the plan and start again because you've ended up with the service entrance being located right next to the main entrance.

Re:Hell no

[smallfries]

If an abstraction is clean, and has zero leakage then it is fine to not understand what it is hiding. I don't know of any such things in CS, but sure in theory it would work.

Re: Hell no

[Anonymous Coward]

Funny, only the other day I was reading an article on how a michelin star famous restaurant was paying chefs less than legal minimum wage. Meanwhile all the subpar programmers I know are earning above median wage. Perhaps some shill accounts on here are trying to drive down wage expectations for knowledge workers, do you think?

Re: Hell no

[fisted]

Yes, my UID fits in an unsigned short. So?

It does not.

Re: Hell no

[fisted]

Oops, actually, it does. Never mind, I was thinking the smallest allowed range of unsigned short was [0,255].

Re:Hell no

[Rande]

I used to. When the only tool you have is a sector editor, all your problems are solved with 21, 00, 00

Re: Hell no

[Drethon]

“Computer Science is no more about computers than astronomy is about telescopes.” - commonly attributed to Edsger Dijkstra, but disputed.

[...] Mastery of the advanced studies of your discipline will make you a better than merely someone who can just get the job done.

The caveat being here that a good portion of what goes for CS at universities is essentially "How to use the vast resources of a supercluster as a glorified pocket calculator". I had the dubious honour of suffering through four semesters of so-called CS at my uni, and I can attest that you can be an incredible computer scientist and still be unable to program even modestly simple applications. And that is said without even touching upon the vast difference between CS and software engineering (and the equally vast difference between software engineering and programming, to be fair).

All three disciplines have their place. But CS is not exactly the 'advanced study' of programming.

I went through 4 years of computer engineering, some classes were shared with the CS students and some were CE specific. I found that the CE classes seemed to do a better job on focusing on making something and forcing us to learn the theory on our own so we could make that thing. In any of the shared classes the CS students were great in tests but struggled in projects, while the CE students rarely had trouble. The CS students were just as smart but I don't think the focus on theory, rather than application, handicapped them.

I've gone back for advanced degrees in CS after working in development for a few years and the theory courses make more sense as I have the background to see how they could be applied. I really wish colleges would focus more on practical work, rather than theory. Though I have noticed somewhat of a shift in that direction over the past 15 years.

Re:Hell no

[digitig]

I agree; anyone can program, with no special effort required.

Programming so you deliver working and maintainable code on time and to budget, on the other hand...

Re:Hell no

[Bengie]

I have to disagree, programming is easy. The only time programming is difficult is when someone makes it more difficult than it needs to be. I will agree that nearly all of the yak-shaving has been removed making "programming" easier, but it goes back to my first assertion.

Real programming happens in your head or on a white-board with pseudo-code. Pseudo-code writes exactly the same today as it did 100 years ago, one logical step at a time. If Knuth has made pseudo-code easier to write, then I will agree with you, that he made programming easier.

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.

You make it sound like some mystical complex thing. I do think that it is amazing how far computer have come, but I refuse to believe that logic, the cornerstone of programming, is some " deep and mystical" thing. The only thing I am surprised at is how difficult logic is for most programmers and how the state of programming isn't worse than it is.

Re: Hell no

[Anonymous Coward]

Don't feel bad. These things build (unsigned) char-acter. Of course, that's still assuming your architecture has eight bits per byte. -PCP

Re: Hell no

[deysOfBits]

I doubt you could pick up a true functional language in 2 weeks. Programming a concept recursively is not that easy. You have to think totally different. And after a week or so u forget how tail recursion works.

Re: Hell no

[Zero__Kelvin]

Only a person who didn't understand programming would make such a ridiculous statement.

Re:Hell no

[budgenator]

Nah, I've been programming longer than Knuth has, starting with machine language. You just need to think procedurally.

That's a major challenge for most people and the more abstract the procedure the more challenging. A lot of us here "just get it" because our brains are wired that way, if your brain isn't wired that way it's extremely difficult to learn.

Re:Hell no

[zifn4b]

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.

I've spent a good chunk of my career performing optimization of code using these types of principles and I hate to say this but we now live in a world where this knowledge is limited in its application. You have several movements most notably the cloud movement where when you have a performance problem you just spin up more VM's and scale them. On a side note, that's more financially beneficial for cloud providers but we'll leave that for another discussion. Up until about 10-15 years ago, hardware was very limited and you had to make good use of it to get scalability. The next one that's happened over the past 15 years is the wide adoption of "even more higher level languages". Remember when C used to be considered a much higher level language because assembly language was so tedious? Well guess what we have now. We have languages like java running inside of code compiled in C++ which then compiles your java code down into byte code which can directly translate to assembly language. What does this mean? It means that we are now far more removed from access to the metal to even do a lot of the optimizations that we've done in the past. With all these layers of languages you have other problems where compiler/interpreter optimization occurs in different places and that you don't have access to enough of the metal to be able to do adequate optimization anyway.

I don't mean to sound like I claim that attention to optimization is misplaced today. What I'm saying is that the old methods of optimization such as those described in this book that I learned in Computer Science, are not really applicable to programming today. The concepts are sort of useful. If you can understand the mindset required to do effective optimization you can still find creative ways to apply it in today's technology, but it doesn't directly translate. What I do find interesting is that when I look at what we had to do in ye olden days I realize it's a lot less frustrating to be a programmer today than it was 30 years ago.

Re:Hell no

[budgenator]

Dude, NASCAR, you turn left, over and over ...

Re: Hell no

[pruss]

I don't question this, but I wonder how you manage to keep the skill. I used to program Z80 assembly in the late 90s (Sharp organizers) and 8086 in the early 90s, but I can't say that I know Z80 and 8086 assembler anymore.
Or have you managed to keep up the memory by continuing to program antique devices (not a terrible idea)?

Re:Hell no

[budgenator]

Programming isn't terribly complex.

Awesome that you think so! Now, program some realtime flight surface control software for a fly-by-wire jet and sleep well knowing that your program will never, ever, kill anyone... (Or, substitute any other safety critical software you can think of - and theres a lot!)

"Programming" (by which I really mean software engineering) is one of the most complex activities in existence...

Just don't cross the International date line east to west

Re: Hell no

[Immerman]

Really? I remember covering recursion for maybe 1-2 weeks and have been using it off and on for a couple decades. It's not complicated, just different, like almost every other aspect of programming. Head, tail, combinations of both - it's all basically the same logic as you would see in a loop, just organized differently. Some solutions are easier to express recursively. And if they're not, don't use recursion.

Re: Hell no

[AcerbusNoir]

PHP's ease of use and widespread popularity has certainly allowed for the creation of some very hideous abominations. However, PHP itself doesn't deserve the rapp that was brought on by the "know enough to be dangerous" wannabe programmers.

Re: Hell no

[Anonymous Coward]

Probably better for you to pass on the whole online "socializing" thing.

Re:Hell no

[colinrichardday]

The GP may mean that it's difficult (complex) to write noncomplex, but good code.

Re: Hell no

[Anonymous Coward]

This explains the mountains of shot software design we're dealing with today. Those 'designers' are just as moronic as their code 'monkey' counterparts.

Re: Hell no

[Anonymous Coward]

This.

In fact several of the earlier classes (algorithms and data structures) were taught in a non-existent language, which looked vaguely like Pascal and we did the assignments in PL/I. In the scheduling and simulations class we had assignments in three different languages (GPSS, Simscript and Simula). We taught ourselves PDP-11 assembler for the minicomputers class. (Later I taught myself PDP-8 binary machine language so I could hack an RJE station controller on campus. Also APL to go beyond the canned functions for the statistics class.) And so on.

I have the first three volumes of TAOCP, and I've skimmed them and used them for reference, but not lately. I think for the last decade they just help anchor one end of a bookshelf.

As for astronomy and telescopes -- in fact in my astronomy & astrophysics course we spent a week or so on telescopes, so we'd understand things like diffraction limitations and so on. In my microbiology class we spent some time on microscopes. You can't do good science without understanding the limitations of your tools. But no, they're not about telescopes or microscopes or computers.

Re:Hell no

[slew]

Driving a car isn't hard millions do it.

I've waited until I was 37-years-old to learn how to drive. My father wasn't going to teach me as a teenager to drive stick on his one-ton flatbed that he put a million miles on in ten years. Since Silicon Valley has a well-developed transit system, I got around just fine without having a need for a vehicle. One day my father abandoned his old car in my carport. I had not choice but to get my driver license and take possession of the car. Took me three years to find out about all the repairs that he didn't tell me about. It's easier to own a car when you're more mature and financially responsible, especially if your father is DIYer who doesn't believe in mechanics.

I'm calling BS on Silicon Valley having a well-developed transit system. You may be confusing SV for SF. VTA transit routes (e.g., the transit agency responsible for mess that is silicon valley) have decided that the only viable transit corridors/routes are south san jose to downtown san jose and mountain view to cisco (aka north-sanjose). Ever other place gets fragmented bus service with no-transfers (I guess if you are a monthly pass owner you don't care about cost of transfers). With the current frequency, each transfer can cost you 15-20 minutes, it can take hours to get to where you are going. Local companies have pretty much given up on VTA and fund their own shuttles to Caltrain for the last mile, but that doesn't fix the "first-mile" issue (getting from your apartment to Caltrain or light-rail).

For example, in my old place, I tried to commute by bus for a couple weeks when my car was in the shop. Luckily I lived only 3 blocks from the nearest bus service, but that's because that bus winded through neighborhoods to get to the Great America transit area (where lots of bus lines intersect/terminate) just to get another bus to my job in Santa Clara (in the heart of Silicon valley) which terminated in a walk of about 15 minutes to my office. Total transit time by bus during commute time 1.3 hours vs average time in car 20 minutes. Needless to say, after 2 days, decided to rent a car. I used to also used leave my car at the office and got to SJC airport for weekend trips. The office to SJC (which is 10 minutes by car) required a 10-min walk, two buses to eventually get to Santa Clara Caltrain station where I could take the VTA flier (bus route 10), took about 50 min to an hour (again because of transfers)...

Because Silicon Valley is so spread out, the bus transfers and the frequency are total killers in trying to get from point-A to point-B (unless those points are walking distance to light-rail or caltrain). Even on medium frequency routes, there is little bus service because it centers on community college routes and retail locations like the El Camino Real corridor (which they are looking to upgrade) and the 87-to-cisco corridor. Unfortunately, it's a pain in the ass for any other potential user because sub-urban sprawl makes the population density sucks for bus service.

Yeah I voted for the VTA tax increase, but I have the suspicion they are probably just gonna spend it on prep-work for the California high-speed rail project, not making any better transit system in the valley...

Re: Hell no

[Bengie]

PHP has many many idiosyncrasies that violate the principle of least astonishment.

Re: Hell no

[Bengie]

Programming is made to be complex. Unlike surgery and aerospace engineering, you make up your own rules with programming. It's like you can make a virtual world with all kinds of useful laws of physics. Of course, the more complex you make these laws, the more difficult it becomes. Most programmers, given enough time, will turn any project into a ball of mud.

Re:Hell no

[Dareth]

https://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html

Dijkstra on Cobol and Basic. Bias worse than yours towards PASCAL, even if it happens to be true.

Re: Hell no

[fisted]

Don't feel bad. These things build (unsigned) char-acter.

Tee-hee.

Of course, that's still assuming your architecture has eight bits per byte. -PCP

No, none of that assumes anything 8-bit, except by that fact that CHAR_BIT cannot possibly be *less* than 8.
And even then, the minimum allowable ranges of integer types are actually specified in terms of intervals, not in terms of bit widths.
I.e. it's perfectly valid to implement C on a 13-bit platform and still have unsigned char be able to hold values no bigger than 65535. Likewise, regardless of how many bits per byte, signed char need not be able to hold values outside [-127, 127] (no, not -128)

(My brainfart does not mean I don't know my C.)

Re:Hell no

[Tablizer]

You are correct. Thanks for clarifying that.

It takes a lot of thought processes to write simple (and good) code. It's kind of like writing in general (text). It's easy to write out thoughts, but for most it takes a lot of work to make it clear and compact.

I can re-visit any page of manuscript and code I've written and usually find ways to simplify and improve it: remove redundancies (factor), use better variable names or pronoun references, etc.

And I'm sure if more readers visits it, they will have suggestions for further improvement: more perspectives help. I know how my head processes info, but we are usually writing for other heads.

There is probably a point of diminishing returns, but the first few drafts of code or manuscript are rarely close to being optimized.

Re:Hell no

[aldousd666]

The pascal article was satire, in defense of abstractions by "Ed Post" (whose name I thought was a stand-in for 'editorial post' when I saw it,) in 1982. A lot of the crochetty old nerd guard was getting antsy about making computing into the use of a 'black box' or simply bragging about their arcane skills, and bemoaning that the programmers of today wouldn't be able to hand toggle their way out of a locked filing cabinet. Same as some linux folk (who are becoming increasingly rare,) who insist that anything you can't do on a command line isn't worth doing. Like all satire, there is some merit. But mostly it's just good laughs of the "Get off my lawn" variety. Thanks for that link.

Re:Hell no

[__aaclcg7560]

I'm calling BS on Silicon Valley having a well-developed transit system.

I live in San Jose and work in Palo Alto. Most mornings it takes me exactly one hour from my front door to take a local bus down the street, pick up the express bus to Palo Alto, and another local bus to the front door of my workplace. The afternoon commute is one to two hours long, depending on 280 traffic. Or four hours if a gravel truck spills across all lanes like it did a few months ago.

http://www.nbcbayarea.com/news/local/Gravel-Truck-Overturns-Blocks-Multiuple-Lanes-on-I-280-394043641.html

VTA transit routes (e.g., the transit agency responsible for mess that is silicon valley) have decided that the only viable transit corridors/routes are south san jose to downtown san jose and mountain view to cisco (aka north-sanjose).

That's correct. Homes in the South and jobs in the North determined the transit lines back in the 1980's. VTA was supposed to have a half-dozen East-West light rail lines but those were never built. When San Carlos got shutdown as a street through San Jose State University in the 1990's, the county built the foundations and covered it up with 18 inches of top soil for a future light rail line. The only major East-West line being built is the BART extension from Fremont.

Santa Clara (in the heart of Silicon valley)

Santa Clara (Intel) haven't been the heart of Silicon Valley in decades. It's Menlo Park (Facebook).

[...] (unless those points are walking distance to light-rail or caltrain).

That's why mixed-developments with stores on bottom and four story of apartments on top are sprouting up along the transit lines. If you don't live near a major transit line and don't work near a major transit line, blaming public transit isn't going to fix it. I live near several major transit lines, so I'm an hour away from work in North San Jose, Mountain View or Palo Alto.

Re: Hell no

[Bengie]

It is often said that a software architect is your best programmer. The architecture is highly dependent on the implementation and the implementation is highly dependent on the architecture. If the architect is not good at implementation, you get an ivory tower issue.

It is actually part of the architect's responsibility that they make sure the system is implemented the way they envisioned. Leaving the implementation details up to the developer or programmer is just asking for trouble. The responsibility of the architect does not stop at the software. They are also responsible for the hardware and network.

The architect is supposed to take a holistic approach and understand EVERYTHING from security to hardware to optimizations. Ideally, you have exactly one architect and everything is made to fit their vision. In practice, people leave companies, take vacations, and other thing happen. You might have one or two co-architects. It doesn't matter the size of the project, one person to rule them all. If you have more than one person, you will not get seamless integration among the many systems. The end goal is you have one unified vision, and you can't have that with more than one leader.

Re: Hell no

[Anonymous Coward]

Have you ever written code targeting platforms like the HP Saturn family of microprocessors? Such machines use nibble-based addressing, where the smallest individually addressable unit is 4 bits wide, so you might quite sensibly elect to "#define CHAR_BIT 4" for certain toolchains operating in such environments. Provided you don't have any insurmountable technical requirements stipulating C89 or later so far as "standards adherence" goes, this would be fine in terms of "K&R C." CHAR_MIN and CHAR_MAX are entirely separate concerns, though. -PCP

Re: Hell no

[fisted]

Well I was talking about Standard C (de-jure, K&R C was de-facto at best), but interesting real-world reason to violate it regardless. No, I haven't had the pleasure with 4 bit MCUs yet.

Re: Hell no

[monkeyzoo]

There are designers, who are creative, and programmers, who are code monkeys.

There are binary thinkers, who are tools, and people with cognitive nuance, who are awesome.

Re:Hell no

[Bengie]

Logic is Universal. It does not mean you will come to the same conclusions because of many factors including knowledge, experience, and personal preferences. The logic used to reach the conclusion should be easy to understand for other logical people.

A tip off that you're not thinking logically is if you need to constantly change your mental model. There has been research where a logic test is given to students entering a Computer Science major. They used a pseudo-code language with no rules given and told the students to interpret it. Several examples of input and output for the language were supplied, then a question was asked about a different input, what was the expected output. They gave this test several times throughout the student's carriers. consistency was key. Students who came to the same conclusion, even if they were "wrong", were typically the best programmers. They even tried this test out on students with zero programming background and in other majors, and they got similar results.

Regardless of knowledge or experiencing gained, if you can't come to the same conclusion for a logic test, it's because you're not being logical.

How long does it take you to buy toilet paper?

[Anonymous Coward]

Two decades THINKING about buying books? Jesus Christ. Just go buy them. You are ridiculous.

Re:How long does it take you to buy toilet paper?

[iggymanz]

better yet, just steal it for awhile, the torrent with all four volumes is out there. Look it through and if it's worthwhile buy it.

Yarrrrrrr, yo ho yo h,o a pirates life for me....

Not yet

[Anonymous Coward]

I'm busy reading "Mein Kampf" trying to figure out what goes on in Donald Trump's head.

Re: Not yet

[Anonymous Coward]

We now know what goes on in yours

Re:Not yet

[Anonymous Coward]

In that case you're probably better off reading this book...

got the set at my desk

[Anonymous Coward]

I still have it at my desk, though I only have the 4 volume set.. I think its been slightly expanded a few times in the past decade. And yes, I actually enjoyed reading through it a few times

Never admit

[nicoleb_x]

Jeez, do you really think you'll empress anybody by having read the series, or claiming to have read the series? I get laughed at when I suggest memcached because all the cool young programmers "know" that redis is where it's at. You think anything written by anybody 77 years old is relevant?

Re:Never admit

[110010001000]

empress? memcached? redis? You guys have strange names for programs.

Re:Never admit

[93 Escort Wagon]

You think anything written by anybody 77 years old is relevant?

So I take it you think K&R is irrelevant as well.

Re:Never admit

[Pseudonym]

I get laughed at when I suggest memcached because all the cool young programmers "know" that redis is where it's at.

I had to look up this "redis" thing. I saw on the front page that it supports geospatial data. Then I looked up what constitutes "geospatial data" as far as redis is concerned. Then I cried a little.

It might be a fine product at what it was designed for, but any time I see people throwing around big words that they don't understand, it's a safe assumption that what they're trying to sell me is a toy.

Re:Never admit

[Anonymous Coward]

"you'll empress anybody"

I LOL'ed.

Re:Never admit

[kriston]

Those dumb names, like the silly "MongoDB," were just created to encourage the hyping of their technologies, even though they are simplified and inadequate versions of what was earlier well-tested and battle-proven.

Re: Never admit

[Anonymous Coward]

It's terribly difficult to empress someone. There are claims of royal lineage to sort out, golden carriages to arrange, diamond tiaras and suchlike.

This is going to be a very short Ask Slashdot

[Anonymous Coward]

No.

Torn between reading and doing

[mykepredko]

I read the first three books in University and did examples from the first two when I started debating with myself, friends and professors, is it better to have the ultimate reference or be able to create code on your own as the requirements come up?

Over the thirty plus years since, I'm happy to say that volume two and three have gotten pretty ratty as I've used them as references (along with "Programming in C", 2nd edition) so I feel like I've struck the right balance (for me) between reading them, using them as reference and creating my own code/algorithms.

Re:Torn between reading and doing

[fermion]

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.

Re:Torn between reading and doing

[jnaujok]

Few developers are going to have to know how to really code, or what is really happening in the engine they are using.

And THIS is why I get paid nearly twice as much as all the people I work with who fit exactly this mold. Because when you do understand how the code really works, you can make software perform better than anyone believes. For example, 10,000 complex business logic transactions per second with database and third party interactions on 3 boxes of physical hardware with a total cost under $20,000. (Probably less if our ops people didn't insist on IBM branded servers.)

Daughter was a big fan when she was younger

[93 Escort Wagon]

Although she preferred his other works, like The Land Before Time and Anastasia.

I read it

[Anonymous Coward]

And all I got was a tshirt.

May the Source Be With You

[ramorim]

Just buy it (the entire and updated book set) and read it ;) and continue to use it as a permanent reference for whatever you want to do with programming...

Re:May the Source Be With You

[budgenator]

Is the updated bookset typeset in TeX? If it's not typeset if TeX, or LaTeX as a minimum all of the mojo is gone!

Read the first volume

[guruevi]

It's really great reading if you do stuff like program low-level (think C, Assembler), efficient programming or do stuff close to the hardware level (such as microprocessors). It describes the very low level of a program and a computer.

If you're into a higher level of programming (Java, C#, Python etc), unless you're building libraries for it, it is probably going to confuse you, most of the 'hard stuff' is (double precision, floating point, sorting and searching through lists ...) abstracted away. Obviously 'someone' has to know how it works in the end, someone has to write the compilers, I haven't started on the rest of the volumes because that's not "me".

You should understand how computers work before you start reading these, I've been in the 'business' for 20 years, I've read it 3 times just to get a basic grasp on the first volume.

Re:Read the first volume

[Anonymous Coward]

I've read it 3 times just to get a basic grasp on the first volume.

The introduction to the first volume actually suggests doing precisely that. Knuth knows that programming is difficult. He wrote the books in such a way you could read them and skip the gory stuff the first time around. He even marks the stuff that is gory with special notations so you can avoid it if you want to.

I've read about half of the first book. It's a difficult read between full time work, family and social lives, and other commitments that I like to have. It is worth a read though. I am seriously considering an electronic copy just because it's the kind of thing that's really useful as a reference and really heavy to carry around everywhere I might need it.

I am also tempted to try the example problems in a new language just to reinforce the new language for me. But that always takes a back seat to other things unfortunately.

Re:Read the first volume

[swillden]

It's also well worth the effort (and it is a lot of effort) to read the third volume, Sorting and Searching. The second volume (Seminumerical Methods) may be useful if you do certain kinds of work, but Fundamental Algorithms and Sorting and Searching are worth almost any professional programmer's time.

I have to admit I haven't bought 4A yet.

I really hope that Knuth is grooming someone to take over the work of completing the full set when he dies, or becomes unable to continue.

Re:Read the first volume

[un1nsp1red]

It's a difficult read between full time work, family and social lives

Who let this guy in here? How'd he get past security?

Re:Read the first volume

[globaljustin]

good one

Re: Read the first volume

[Anonymous Coward]

How do you tell the security detail for a nerd hangout? They're the ones with their uniforms' trousers pulled over their head.

Re: Read the first volume

[Anonymous Coward]

Who let you in here? Real nerds don't have a sense of humour ;) The reality is that most good programmers don't own pocket protectors, let-alone need revenge.

Re:Read the first volume

[whit3]

It's also well worth the effort (and it is a lot of effort) to read the third volume, Sorting and Searching.

I've greatly enjoyed the first three books, and especially Sorting and Searching. The chapters are independent, so you can treat the volumes as a collection of nonfiction short stories. I recommend it as bedtime reading.

Except, these short stories open up possibilities, and contribute to my understanding of ways to handle tomorrow's problems. There are three kinds of computer books: ones that teach one tool (pretty useless ten years later, when the tool obsolesces), ones that teach from the bottom up (again, pretty useless when 6502 is replaced by 65816, and in turn 68000, 68040, PPC601, PPC603e, G3, G4, G5, core duo, Xeon...), and those that teach from the general principles (top-down style).

Algorithms knowledge at the mathematical-tool level really REALLY helps sometimes. And it remains helpful forever (like the Pythagorean theorem) rather than becoming quaint (like the art of making an '035 keypunch program card).

Re:Read the first volume

[TheRaven64]

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.

Re:Read the first volume

[angel'o'sphere]

Learning an Assembly language, especially 6502, is not that useless.
First of all it makes learning other assembly/machine languages easier.
Secondly, that is why I said "especially 6502", you learn that your language is so limited that you most likely want to use it to implement your own mini virtual machine like Sweet16.
The particular interesting thing about the 6502 is: it was designed to have a minimalistic 8 bit opcode set, with 127 free to use 16 bit registers in the so called "zero page".
Yes: 16 bit "registers". Ofc. they where not registers in the sense of a true processor register. However programmers used them to implement all kinds of "pseudo code" VMs.

Re:Read the first volume

[Tablizer]

It's a difficult read between full time work, family and social lives

Who let this guy in here? How'd he get past security?

Via social engineering, of course.

Re:Read the first volume

[HiThere]

Not really. One should read the first part of the first volume, but it's general use is as a reference book(s). I have frequently gone back to parts of volume 2, but I've rarely needed the other volumes. For awhile I was planning to learn MIX but instead I only skimmed over it...and instead learned CDC 6400 assembler, which I had a practical need for. But the first part of volume 1 should be considered mandatory. Read it, know it, and build it into yourself so deeply you forget it...the knowledge is just implicitly there.

Re:Read the first volume

[Anonymous Coward]

> program low-level (think C, Assembler)

I remember when only one of those was considered low-level.

A SkyRim Read? Then Yes.

[xxxJonBoyxxx]

I read the three volumes like I read any book in SkyRim: I opened the cover, got my +1 level in computer science, dropped it and hit it with a fireball.

Re:A SkyRim Read? Then Yes.

[Anonymous Coward]

As an ex-assembler programming, C compiler writing, SkyRim playing sort of guy, I really did laugh out loud when I read your comment.

Brilliant! :))

Re:A SkyRim Read? Then Yes.

[Anonymous Coward]

I read the three volumes like I read any book in SkyRim: I opened the cover, got my +1 level in computer science, dropped it and hit it with a fireball.

I used to read computer science until I took an arrow to the knee.

Absolutely. If you want depth, read it.

[alvarez.pablo]

It's definitely worth reading, and working through at least some of the exercises. It is an excellent example of rigor, depth, and attention to detail. You may not have time to work like that every day, but it's very useful to be capable of doing it and to have a good mental model of what it's like.

Parts

[Erich]

TAOCP is a great reference. There are some really important things that are pretty good for someone who wants to be a professional software engineer.... 0) understanding how algorithms execute on a processor. While MIX is behind the times, (and MMIX is ahead of the times in many ways) understanding how an algorithm executes on a processor is important. I think Knuth really did the right thing in not selecting the language of the day. 1) algorithm reference. If you need to understand an algorithm, or choose between a family of algorithms, it is often a great place to find the art. 2) The humor is pretty good, at least to me. Done get me wrong, it's on a humor book, but there is wittiness and puns and some running gags... 3) It's always good to have some humility, and reading TAOCP always makes me a little more humble. It's worthy of a place on your shelf.

Re:Parts

[dargaud]

I read the 1st volume when I was a high school student in the 80s. I knew Basic and Assembly and some Forth at the time. Book 2 and 3 weren't available at the library at the time so I never got around to read them. Anyway, my question is: what is MMIX, and how does it differ with MIX which was rather limited, even for the 6502 programmer I was at the time ?

Re:Parts

[cruff]

Anyway, my question is: what is MMIX, and how does it differ with MIX which was rather limited, even for the 6502 programmer I was at the time ?

MMIX is a 64 bit RISC-like processor that reflects where CPUs were headed in the 1990-2000 time frame. I found the algorithms coded in MMIX assembler to be much easier to understand than the original MIX versions. There are one or more simulators and tool sets available for it if you want to actually test some code.

I just DO it & folks like it... apk

[Anonymous Coward]

his hosts program is actually pretty good by xenotransplant

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg

I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

take a look at the APK hosts file engine by SuperKendall

APK is kinda right. I've tried his hosts file generating software. It works by bmo

APK is totally right on this count. Adblock Plus on Firefox mobile is a dog on older, or lower end, phones. A hostfile based adblocker makes for a much better experience by chihowa

I like your host file system by Karmashock

I find your hosts file admirable by vel-ex-tech

* My code's liked/used + recommended & hosted by Malwarebytes' hpHosts - Argue w/ those folks above (or success).

APK

P.S.=> I have more like 'em if anyone asks.... apk

Re:I just DO it & folks like it... apk

[110010001000]

Your closed source code is full of malware. No one should use it.

Re:I just DO it & folks like it... apk

[Anonymous Coward]

It's pretty clear apk hasnt read many books on computer programming or anything else for that matter.

If you want to write a book, just do it

[KalvinB]

Sure, yeah, you could take a few weekend courses and bang out some stuff and possibly even find a job paying decent money.

But if you want to move up in the world you need to turn your hack and slash techniques into a refined art.

The kind of crap commodity programmers write is the stuff that skilled developers get paid a lot of money cleaning up or just re-implementing.

It the difference between dime store trashy romance novels and real actual novels. The different between the the Divergent movies and Hunger Games.

If you're content being a direct to DVD wholesaler of crap sure, just get to work.

If you want to work in the big leagues on important things, you need to be open to learning some things and respect the craft.

Re:If you want to write a book, just do it

[110010001000]

Nah, not really. I've been doing it for decades on important things. I never read it.

Re:If you want to write a book, just do it

[Anonymous Coward]

Are you actually comparing American TV to fine literature?

Re:If you want to write a book, just do it

[un1nsp1red]

The different between the the Divergent movies and Hunger Games.

Soo....it's basically the same?

Re:If you want to write a book, just do it

[CrashNBrn]

The different between the the Divergent movies and Hunger Games.

And which of those isn't the dime store trashy novel?

Re:If you want to write a book, just do it

[Kjella]

Sure, yeah, you could take a few weekend courses and bang out some stuff and possibly even find a job paying decent money. But if you want to move up in the world you need to turn your hack and slash techniques into a refined art. The kind of crap commodity programmers write is the stuff that skilled developers get paid a lot of money cleaning up or just re-implementing. (...) If you want to work in the big leagues on important things, you need to be open to learning some things and respect the craft.

With all possible respect to all the CS experts of the world, that's not what they teach. Finding a good organization of your application that makes structures easy to break down, processes easy to follow and changes easy to implement doesn't involve deep, abstract mathematical formulations with optimal answers. It's about creating functional units (objects, layers, modules, services) with clear responsibilities that abstract away internal details, create well defined and narrow interactions, break up and explain complex logic, that everything behaves like and contains what you'd expect from common language definitions and naming conventions and with sufficient high level documentation that anyone of moderate intelligence can understand what bits need to go where.

Or to put it another way, if you sent the source code through an obfuscator the CS experts would probably be just as happy with the output as the input, after all the algorithms and functionality are all unchanged. It would make it an incomprehensible mess of spaghetti code and "there be dragons" that nobody understand how or why works, but those are practical concerns. The same is error and exception handling, CS is all about correct algorithms that never get called with invalid input or run into any of those practical problems that cause poorly written software to crash, often without leaving behind any useful reason why and if there's any possibility to just fail this and move on.

I think you're onto something about the craft and the art. If you want to make swords for an army it's a craft, if you're making a nobleman's fine blade it's an art. Most of the time what we want is robust craftsmanship, process as many passable swords as possible and discard any failures. Not very glamorous and not very artistic, we're not awarding points for style or elegance but whether the code you've built is a reliable work horse that gets the job done. Or maybe the difference between an institutional chef and a fine dining chef. One is serving a hundred people a good meal, the other can spend forever making a plate of fine art. Both are very different from being a poor chef, but being good at one doesn't really make you good at the other. And CS is the Michelin guide department.

Re:If you want to write a book, just do it

[phantomfive]

With all possible respect to all the CS experts of the world, that's not what they teach. Finding a good organization of your application that makes structures easy to break down, processes easy to follow and changes easy to implement doesn't involve deep, abstract mathematical formulations with optimal answers. It's about creating functional units (objects, layers, modules, services) with clear responsibilities that abstract away internal details,

I'm not sure about your university, but my professors tried to teach that in addition to the math stuff.

Re:If you want to write a book, just do it

[Sique]

One of the most important chapters in my basic CS courses was "robustness", the ability of algorithms to still work correctly even if fed random or maliciously formed input. The mantra of the teacher was: "Never expect input to be what the spec says."

Re:If you want to write a book, just do it

[passionplay]

I think you skipped the class on Finite State Automata and the resulting literature that came from that particular line of study such as the GOF. You probably use it all today but you just don't realize it. Computer programs done w/ the predicate calculus express truths. If those truths have the finite set of transformations that maintain those truths, the program is still true and correct. We often sacrifice this process in interest of speed. But it does not mean that the resulting code does not show evidence of that series of transformations. It does however show evidence of corners being cut and that someone manually crafted the organization. So the program instead of being itself a proof of correctness that always works, is rather an approximation (first order or better) that covers the majority of cases required and then there is some sort of error catcher (often incomplete) for the rest.

Re:If you want to write a book, just do it

[serviscope_minor]

I've been doing it for decades on important things

All working on important problems means your employer has to spend all the more drafting in professionals to clean up the mess after you're done with it.

Re:If you want to write a book, just do it

[Rockoon]

More likely it is that what he thinks is important actually isn't.

The masters dont just write an algorithm, they prove metrics about it. They prove that its O(n log n) worst case complexity, that it only ever needs O(n) space, that it will recurse O(log n) times at most, that it handles all possible inputs, and so on.

When the worst thing that can happen is that you have to restore from backup and you lose a little uptime, then you arent working on important things. When the worst thing that happens is that you just sold a hundred thousand time bombs that will cost millions to recall or patch, then you are working on important things.

For those that dont get it, I present to you exhibit A: all the problems we have seen with SSD firmwares because they hired monkeys instead of priests.

Re:If you want to write a book, just do it

[Bongo]

There's an expression I'm fond of:

"Organisms organise."

Re:If you want to write a book, just do it

[Bengie]

Empirical evidence lies. I have seen O(1) algorithms that run faster on large datasets than O(log n) for micro-benchmarks, but once you put the algorithm into prod, the random memory access was trashing the cache and made it slower while increasing jitter in the system. I told them they were wrong well before they even started performance testing because I thought about the issue for a minute or two.

Metrics are only as good as the person interpreting them.

huh?

[smithcl8]

I thought everyone learned from a Dummies book and building a few cell phone flashlight apps.....

Cat got your tongue?

[Anonymous Coward]

No, but the poser child from a private university that is friend of the boss claims that will publish erratas to all volumes available or when they are published.

Disclaimer: Post this as "funny" but this actually happened with some dork project leader in Java from a consulting firm around 2006.

Improved open source program.

[tenter]

I used Vol. 2 to improve the multiply algorithm in an open source program.

I have read some

[hgriggs]

I have them. I have studied small parts of some of them. I have been delving into them over 30 years.

For day to day programming, I do not need or use the detail in those books.

At various times in the past, I have delved into library writing, and then they were very helpful, mostly in understanding issues and problems that I had not thought about. But I think time has moved on. Hardly anyone needs the details in those books, and in many cases, some classes of problems are well solved.

Looking back, I am glad that I studied some parts. But today I would not recommend them. Unless you really wanted to look back at history.

It's highly overrated

[Anonymous Coward]

The writing style has much to be desired. The code fragments do not follow any of the modern practices. Heck, if I remember it correctly, Knuth actually starts by explaining what pseudo code is and how it is for some imaginary machine to illustrate the point. These books were not written for the modern audience. His audience were his contemporary who worked with computers. Those people typically had a background in math and not in computer science. And the computers they used required very different kinds of considerations since memory and cpu were very expensive and you had to make your algorithms work under tight constraints. So the algorithms are cryptic not just because good languages did not exist back then, but because Knuth writes them in such a way as to run in a few KB of memory...because that is just how you wrote code in those days...worrying about where on disk the data resides and how to take advantage of the next memory location that the data resided on.

This is not to say that the Knuth doesn't know what he is talking about. But rather the knowledge he presents is now also possessed by many others who can articulate it better. Do yourself a favor and stay about those books. The subject matter has been covered to death in many other books. And understanding it will not turn you into some kind of a CS god, thought you may get the same kind of satisfaction a person could get from completing a marathon or climbing Everest.

Re:It's highly overrated

[guruevi]

CPU and memory are still very expensive, especially on the mobile market and efficient programming and memory management is still very relevant especially as large swathes of memory is becoming scarcer. But there are still plenty of people using microprocessors that have no more than a few MHz and several kilobytes of memory.

Even the Arduino libraries themselves are rife with examples of such 'bad' programming, some operations unnecessarily take many more cycles than necessary while using a simple example in Knuth's books shows how to do it in one (such as bit shifts).

Re:It's highly overrated

[globaljustin]

Great analysis thanks

Re:It's highly overrated

[globaljustin]

Arduino libraries themselves are rife with examples of such 'bad' programming, some operations unnecessarily take many more cycles than necessary while using a simple example in Knuth's books shows how to do it in one (such as bit shifts).

OP said other books have covered these needs better, in OP's opinion.

You do make a good point however, there will always be people cramming circuits into smaller and smaller things and some code has to run them.

Re:It's highly overrated

[ChrisMaple]

I found his books difficult to use. I read them to understand particular algorithms, but when it came to actually writing code to implement an algorithm I had to go to other people's books.

Re:It's highly overrated

[Anonymous Coward]

Even the Arduino libraries themselves are rife with examples of such 'bad' programming, some operations unnecessarily take many more cycles than necessary while using a simple example in Knuth's books shows how to do it in one (such as bit shifts).

Do us a favor and go ahead and name 2 or 3 specific examples.

Re:It's highly overrated

[Anonymous Coward]

> And the computers they used required very different kinds of considerations since memory and cpu were very expensive and you had to make your algorithms work under tight constraints

it is very dangerous to think of CPU/memory as cheap. It invites lazy programming that I have to come and fix later :)

The memory and CPU are there to use when you need them, but each time you think about adding a feature or modifying some software, you should also be considering the best algorithms and data designs to use. You should be thinking about network latency if your writing a networked app. You should also be considering how well your design will scale if you have 10x or 100x or 1000x or a million times the data you are currently testing with. You may be able to justify that a scaling will not be a future problem with this feature, but the process of thinking through it will let you decide what places to spend your optimization time, and may provide an insight into writing it better in the first place.

No, even though I have degrees in math and CS

[Anonymous Coward]

This book is to computer programming as quantum physics is to rebuilding a car motor.

Yes, and it's good. but not gospel

[Anonymous Coward]

It depends on what you mean by "work through it". Do all the exercises? Some are unsolved problems, so that's not terribly realistic.

There's nothing in the books that's not also discussed elsewhere (with the possible exception of the very thorough discussion of out-of-core sorting with tapes, which is a bit unusual these days), but it takes quite a few other books to equal the series.

I have read it at length, and it's definitely full of good stuff to know, but it really depends on your field. It's still dedicated to single-threaded algorithms, so concurrent and functional data structures aren't touched. If you're slinging matrices around for computer graphics, not so much.

But I definitely feel that it covers a greater span than, say, the CLR textbook Introduction to Algorithms.

Why don't you read some in a library (or download some of the torrents floating around) and see what you think? It's a reference book, not a mystery novel which isn't nearly as good if not read in order.

Obsolete -- 40 years ago

[Latent Heat]

Overrated? I thought it was obsolete -- post "Goto Considered Harmful" back when Vol 1 was assigned in a university course -- 40 years ago.

OK, there is insight into algorithms, but from a programming best-practices standpoint, it is just not there. Even assembly language offers structured branching and looping. And if your macro assembler doesn't, structured branching and looping is a good practice for arranging your JMP statements. Simply taking JMPs into and out of your main loop was never a good practice to confer clarity of what your algorithm is doing, let alone establish provable conditions your code meets.

58++ sources make you eat your words

[Anonymous Coward]

See subject 110010001000 & https://www.virustotal.com/en/... (Verified by Malwarebytes' S. Burn "seen the code & it's safe" http://forum.hosts-file.net/vi... )

* Libel will get you NOWHERE vs. facts you can't validly technically overcome loser... lol!

APK

P.S.=> Face facts you FAKE NAME online using fool (for your FAKE life) - you WISH you were me... apk

Re:58++ sources make you eat your words

[Zontar The Mindless]

Please rest assured that absolutely no-one wishes they were you.

Re:58++ sources make you eat your words

[Anonymous Coward]

Nobody wishes they were a sad ass lunatic malware author troll like you APK,

Re:58++ sources make you eat your words

[Anonymous Coward]

You make sense and I wish to subscribe to your newsletter. I would like to run your software on my machine. Does it work with the current release of Temple OS? I have heard only APK hosts is the best of all bests and I must use it for the most safes internet and much speed. PLZ MAKE IT FOR TEMPLE OS NOW I DON'T THINK I CAN RISK connecting to the INTERNET again until I have your best software.

Re:58++ sources make you eat your words

[Anonymous Coward]

It's 110010001000 he's talking to; that's one troll who probably would rather be at least as smart as apk.

Re:58++ sources make you eat your words

[Anonymous Coward]

I'm sure this will be included in his next lkst of "testimonials". Its amazing how stereotypical autistics can be; see apk vs chris chan.

I have, not worth it

[AuMatar]

Don't get me wrong, Knuth is a genius. If you need to do deep research on sorting algorithms, definitely read it. If you want to do CS research and need to learn how to read research papers, its a good start. But you aren't going to get any deep insights on how to write a good program from it. Its too academic and far too focused on deep research. And even for the topics it does cover, unless you want to do research on how to really optimize the hell out of them you're better off using tutorials written for a more practical level.

Re:I have, not worth it

[Drethon]

For something on the same type of topics but I found a little more readable, my algorithm design class used this book: https://www.amazon.com/gp/prod...

I've found this to provide some drastic speedups for some methods of searching and sorting I wouldn't have otherwise considered. Many of the methods are really pretty simple once you understand them.

Do it.

[darkharlequin]

Read at least the first volume, even if you have to check it out of a library.

Re:Do it.

[__aaclcg7560]

I checked out my code base. I couldn't find that text in any of my library files. :P

Maybe

[kwerle]

I wasn't sure if I'd read 'em. I know a friend/colleague (who I regard highly) who has - and I think he thinks highly of them. But he also has terrible taste in movies.

A quick google search landed me at http://broiler.astrometry.net/...

I have not read it.

I've been coding professionally for 25-30 years, depending on how you count. I studied CS in college. I've read a few outstanding books on the subject since then.

I don't have the patience for these, and I suspect I'm not going to miss out on much.

On the other hand, I long ago came to the conclusion that I'm really not interested in low level code. Give me a nice high level language with nice high level functions and features and I'm a happy coder. That's not to say that I don't understand O notation or the costs behind the complexity - but it is to say that I know when to use a drill and when to use a power saw - but I don't want to build either of 'em.

Maybe you're into the nitty gritty. Or maybe you like bad movies.

Check your local tech library and see if you can check out a copy. Or ebay 'em for $20-40/volume. Or if the pdf strikes your fancy, maybe take the plunge.

Re:Maybe

[Anonymous Coward]

You should apologize to that admin. Server went down like a cheerleader's panties on prom night. Good to see an old fashioned slashdotting.

Re:Maybe

[NeoMorphy]

For most development projects, I would agree that going into the nitty gritty can seem like overkill. But, having a core understanding of low level programming can make a huge difference in application performance. The third book "Sorting and Searching" should be required reading for anyone who plans on getting involved with databases, even if they only plan on being a dba.

You can do a lot with high level programming languages, but if you skip assembly or C programming for at least a background on what is happening behind the scenes, it starts to feel more like alchemy than chemistry.

Re:Maybe

[Zontar The Mindless]

No, you just have a crappy Internet connection. Thanks, kwerle!

Re:Maybe

[SciCom Luke]

As a fellow scientific programmer, I am curious to some of those "I've read a few outstanding books on the subject since then." Could you be so kind as to give me a few pointers? Thanks a lot!

Re:Maybe

[AmiMoJo]

I don't disagree with you, but personally it I have a need to know at least basically how things work under the hood. Black boxes just bother me.

It's not just a CS thing either. There are guys like AvE on YouTube who take power tools apart, figure out what type of plastics they used, what kind of motor, type of grease etc.Do a few tests to figure out the design parameters of the electronics.

For me it applies to things other than computers and electronics as well. Social systems, politics, psychology, climate systems, cars, even some higher level biology.

Re:Maybe

[kwerle]

For most development projects, I would agree that going into the nitty gritty can seem like overkill. But, having a core understanding of low level programming can make a huge difference in application performance. The third book "Sorting and Searching" should be required reading for anyone who plans on getting involved with databases, even if they only plan on being a dba.

You can do a lot with high level programming languages, but if you skip assembly or C programming for at least a background on what is happening behind the scenes, it starts to feel more like alchemy than chemistry.

Sure. And I've coded in C (which I think almost has to be true for anyone who has worked in the field for >20 years). And I've written a bubble sort and a quick sort (in college and after). And a tree balancer in college at least. And I just don't feel like I need to slog through a volume on the subject...

Re:Maybe

[kwerle]

As a fellow scientific programmer, I am curious to some of those "I've read a few outstanding books on the subject since then."

Could you be so kind as to give me a few pointers? Thanks a lot!

Ugh. I knew someone would ask that. I don't actually keep a bookshelf with these tomes.

Oh, good - here's an article that has a few: http://www.infoworld.com/artic...

Since college:
"Code Complete" by Steve McConnell (2004)
"The Pragmatic Programmer" by Andrew Hunt and David Thomas

A fun book to do with colleagues:
"Seven Languages in Seven Weeks" - https://pragprog.com/book/btla...

If you're into OO:
"Design Patterns: Elements of Reusable Object-Oriented Software" Gang of four

Not coding, per se, but everyone who works in the field should read and have their boss read:
"The Mythical Man-Month" by Frederick Brooks

The best books from college (I haven't touched in nearly 20 years, but I'm really glad I had 'em back then):
"The C Programming Language" (2nd Edition, 1988) by Brian Kernighan and Dennis Richie
"Compilers: Principles, Techniques and Tools" - the dragon book

Re:Maybe

[DMFNR]

AvE is fuckin hilarious, I wish he had a software engineer twin brother to do similar videos on the software side of things. I've learned a lot from AvE and I appreciate how he's never shy to tell you when he has no clue what he's actually talking about. Just the way it's presented makes me want to go learn more on the subject rather than being overwhelmed or bored by the initial introduction. He's the engineer you want to drink with!

Re:Maybe

[computational super]

like a cheerleader's panties

You knew different cheerleaders than I knew...

Re:Maybe

[SciCom Luke]

Thanks a lot! In exchange, I can advise you to get a 'Numerical Recipes in [language of your choice]'. And if you need any complex snippet of code, make sure that John Burkhardt has not already written it for you: https://people.sc.fsu.edu/~jbu... Have a great weekend!

Re:Maybe

[kwerle]

Nice! Thank you much.

I have read much of it, as I would an encyclopedia

[Ungrounded Lightning]

My wife and I each had a copy of the first three volumes when we married. Yes, there are female computer nerds. B-)

I first encountered it when assigned one of the volumes as a text back in 1971. Of course the class didn't consist of learning EVERYTHING in the volume. B-)

I use it from time to time - mainly as a reference book. Most recently this spring, when I needed a reference on a data structure (circular linked lists) for a paper. I've found it useful often when doing professional computer programming and hardware design (for instance, where the hardware has to support some software algorithm efficiently, or efficient algorithms in driver software allow hardware simplification).

I don't try to read it straight through. But when I need a algorithm for some job and it's not immediately obvious which is best, the first place I check is Knuth. He usually has a clear description of some darned good wheel that was already invented decades ago, analyzed to a fare-thee-well.

I only see him about once a year. He's still a sharp cookie.

Yes

[Pseudonym]

I've read the 1973 editions, cover to cover. I skimmed a few fasciles. Haven't kept up since then.

Do I recommend it? You bet I do, just like I recommend Structure and Interpretation of Computer Programs, The Mythical Man-month, and The Psychology of Computer Programming. That's not to say you have to have read classics like these to be a good programmer, but if you haven't internalised a lot of the material that's covered in books like these, I question how much you care about what you do. And if you don't care about what you do, it will show in the quality of your software.

Buy a set for the US Patent Office

[rowdysailor]

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.

I'll wait until it's complete.

[Anonymous Coward]

I hate reading book series when they're not finished yet. I'll wait until it's all out and then start. :)

Hmm, nah.

[Anonymous Coward]

Seems interesting and well-written, but too outdated and long to devote significant time to now.

Has some neat math in there, but really if I'm looking for that I'm just going to read a math book.

Not Read

[BlackHawk-666]

While I haven't read the books, and doubt I ever will now, the content is similar to the uni course I did in computer science back in the 80s. Knuth covers everything in higher detail than I can recall being taught, but I'm pretty certain my foundations are just fine. It may just be that I'm forgetting some things too, it's been almost 30 years now for most of it.

I might go back and revise a topic or two in those books or a similar source if I felt I needed a refresher. For most cases though, what I can recall is good enough to get through to the solution - or lead me to an online source to crib up on how best to form the solution.

I think if they spent more time today teaching this foundational science in classes, and less time on the latest languages and frameworks, then we'd be seeing a much better class of programmer emerging from education today.

I just DO it & folks like it... apk

[Anonymous Coward]

his hosts program is actually pretty good by xenotransplant

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg

I've never tried to belittle (APK's) work, I've flat out said it's good by BronsCon

take a look at the APK hosts file engine by SuperKendall

APK is kinda right. I've tried his hosts file generating software. It works by bmo

APK is totally right on this count. Adblock Plus on Firefox mobile is a dog on older, or lower end, phones. A hostfile based adblocker makes for a much better experience by chihowa

I like your host file system by Karmashock

I find your hosts file admirable by vel-ex-tech

* My code's liked/used + recommended & hosted by Malwarebytes' hpHosts - Argue w/ those folks above (or success).

APK

P.S.=> I have more like 'em if anyone asks (many more).... apk

Use Set as reference books

[Anonymous Coward]

It is like asking if you have read the encyclopedia Britannia. I bought sorting and searching as one of my first real computer books in 1981. I read the sorting chapter carefully and coded the examples. I found it very useful to understand how many different ways exist to do something.

It caused me to have an open mind because I know I would never have thought of all the different ways to sort data. So I know for any complicated problem I haven't thought of all the ways that it can be done.

You don't have to work through every problem to get something out of the books. As Knuth says himself, some of the problems are actually good candidants for PHD dissertations.

Missing the point

[Anonymous Coward]

The Point is that Knuth was an old white man. He can not possibly have written anything that the disadvantaged urban black latino transgendered americans can possibly relate too. Ohh I know sure you with your Eurocentric attitudes and subconscious racism might find it useful. But you need to step outside and realize that old white men are not running the world anymore. Thank the Goddess this is the case. Let's focus on something all people can get benefit from not just white males. How about commisioning that famous rapper 50 pennies to put programming in the context of hippity hoppity culture. . Yes. That is a book all of the Diverse and Equally Empowered Communities of the Americas could get a use out of.

Face it reading the TAOCP is equivalent to voting for Donald Trump or reading Mein Kampf. We need to ban all books written by old white men. Also we need to keep old white men from voting. They will be dead in a couple years and should not be allowed to make decisions for the millions of black, latino, asian, transgendered, and homosexual people that will have to live in the future Diverse and Equally Empowered Communities of the Americas.

Re:Missing the point

[Anonymous Coward]

Nice satire!

Re: Missing the point

[Anonymous Coward]

It's okay. This is why we have the Rust programming language, and it's Code of Conduct.

Kill all whites.

So can we assume Bill Gates

[slickwillie]

never received a resume from anyone who read the book, judging by the quality of Microsoft's crap?

Re:So can we assume Bill Gates

[hcs_$reboot]

Actually that was in their resume, but nobody at MS had the necessary CS level to ensure the candidate has read (and understood) the books.

Re:So can we assume Bill Gates

[Anonymous Coward]

You do not know much about MS do you?

https://en.wikipedia.org/wiki/...

He *might* know a thing or two about writing OS's.

Rule 1 of Star Trek as applied to Knuth's work

[Anonymous Coward]

"You have to know how things work on a star ship". So true. Folks can wield the latest programming environment and call themselves programmers, nay, software engineers, and accomplish wondrous things. But do they know HOW it works? Likely not. Then some high schooler figures out how to suborn it and cause havoc or make money off it thereby. Because they know how it works.

It's a shame that DK got distracted by Typesetting and TeX for so long. The shaving of such a shiny yak probably lost so many bright minds.

Where's my hallowed copy of Struble?

Re:Rule 1 of Star Trek as applied to Knuth's work

[colinrichardday]

It's a shame that DK got distracted by Typesetting and TeX for so long.

I'm glad he did. I like TeX/LaTeX.

snobbery

[Anonymous Coward]

I bought all three volumes for an ungodly price, thinking it would deftly refine my knowledge of programming. Instead, I got slapped in the face by some wicked esoteric math describing computing. What I did learn is that there is a HUGE difference between Computer Science from the 60's and programming, and that was in the 90's. [I worked at Intel as a DA (cad programmer) in the 90's for a while and brought these books in and asked around, no one could explain them to me. Hundreds of programmers, none understood the books.]

Today? The two barely even meet anymore. Programmers generally don't know dick about compsci. And these books have largely served as namedropping items to put on blogs or CV, because only a very few people I've met in my life have actually understood these books.

Yes, I sound bitter. Because I think we're losing the value of the foundations of CompSci Knuth poured, and I include myself in that condemnation. I wonder how much better a programmer I would have been had I been able to understand these books.

Re:snobbery

[globaljustin]

interesting comment

Yes I worked...

[Anonymous Coward]

through the first three volumes. They are now a permanent fixture on the book shelf of my work desk at home.

Yes....

[Proudrooster]

Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.

We live in an age of cloud computing, load balancers, containers, and distributed databases with stored procedures. When code runs, you have no idea where it is running and how it is spread out over cloud services. Most of the time you don't even know what country the physical box is in.

I have a pure CS degree, but as long as we can keep making things faster and bigger, I am not sure if this book will ever be a top seller. In the brave new world of computing I am not even sure what optimization means anymore. Optimize for CPU, network, compiler, database, cloud architecture??? It is maddening!

As for me, I am currently doing an embedded systems project. Am I doing it in 'C' and ASM like in the good old days? Heck, no, I am using python on a quad core ARM SOC with 1GB of RAM. Even at max processing load I am barely hitting 10% CPU while coding in Python. As long as hardware is fast and cheap, there is no need to spend this kind of time optimizing every cycle and byte. BTW, this is my first Python project. Easy-peasy language that is great for hardware interfacing projects, most libraries exist for common chips like the MCP3008 (AD convertor).

To the kids out there. This is a great time to be alive. You can build anything, learn anything, and talk to anyone. Do cool stuff. Learn everything. There are no limits and powerful hardware is cheap. Look around at how lucky you are to be alive right now. It is an amazing time!

Re:Yes....

[eagl]

Yes but. I used to declare variables overly large as a kludge to help out when error-trapping was consuming too much time and I knew that the compiler wasn't good with overflows. So I'd do input error checking up to the point where it started to take too much time, then declare a variable larger than reasonable input would be, and then attempt to trap and reject input at a length between reasonable input values and the declared variable size. Declaring a variable just larger than the input buffer was one specific way to address attempts to force overflows through buffer overruns. Yes it was a horrible kludge and can't survive any sort of dedicated attack, but it served to deter casual probes looking for exploitable boundary condition errors.

Of course the better answer is to not use an OS and compiler that sucks so bad that the basic io buffers and basic overflows are exploitable, but sometimes you gotta use what you have.

Re:Yes....

[rectalfeeding]

To the kids out there. This is a great time to be alive. You can build anything, learn anything, and talk to anyone. Do cool stuff. Learn everything. There are no limits and powerful hardware is cheap. Look around at how lucky you are to be alive right now. It is an amazing time!

Don't lie to the kids. There are limits. But it doesn't make the gist of your sentiment less worth noting. There is indeed a vast space of interesting things to do within those limits. The basic limit, beyond the less talked about ones, is that you need to somehow provide for yourself and get along in society. However aside from that, with your spare time, a raspberry pi and and a cheap hdtv and keyboard, you can do some pretty amazing things. Add a few things purchased relatively inexpensively from adafruit and amazon, and you can really do some pretty amazing things. It may be a ton of work, you may not cash in on it, but it doesn't take tens of thousands of dollars and a CS degree from a place with expensive big buildings. What was locked away from the masses of past generations in expensive ivory towers can now be burned on a dvd super cheap.

Trump is unfortunate. Keep your head down kids, the shit is going to get thick here for a few years.

Re:Yes....

[tlhIngan]

Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.

Well, does it matter? On a modern system, RAM is allocated in chunks of 4kiB in most architectures. Your variable is going to be either on the stack or BSS section, and really, unless you're really using that page up, using 1 byte or 8 bytes is going to matter not at all because you're really using 4096 bytes and if you're not using it all, it makes zilch of a difference. Loading 1 byte of 8 bytes from RAM to registers still causes a cache line of bytes to be read (16 bytes on a lot of architectures) and fitted into a while 8-byte wide register in the end.

Depending on your needs, using a 64-bit variable to hold 4 bits of data may be more efficient if using 1 byte access causes significant slowdowns because of misalignment.

Hell, the most constrained I've been was using an ARM microcnotroller. It's quite a strange feeling working with 8K of RAM and 16k of flash and yet having full 32-bit pointers and integers

Re:Yes....

[Anonymous Coward]

> eating 8 bytes of RAM, where only 1 byte is needed.

You do realise that an unaligned access to 1 byte is relatively expensive on most of the modern architectures?

Re:Yes....

[Anonymous Coward]

Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.

This may be a good critique of the book. In the present world, algorithms should be written for clarity first, then optimised iteratively with the help of performance instrumentation. A book presuming to "optimise" something for a modern CPU and compiler with pencil and paper is either a brain teaser or an interview cramming tool, not a practical reference: if it works, it's only through heroics and accident, and many people who have mastered it are ineffective programmers.

not to say these books aren't still covering the hard part of the problem, just that they (1) aren't realistic, (2) aren't covering enough of the problem to be effective.

Re:Yes....

[Bengie]

Folks, we live in an age where programmers declare integers that are going to count from 1...10 as LONG INTEGERS, eating 8 bytes of RAM, where only 1 byte is needed.

Then the compiler pads your 1 byte memory location to 8 byte alignment. Unless you have a lot of 1 byte values next to each other. I've seen situations where using smaller data types caused slower performance because of alignment. You may have gained memory at the expense of CPU. At one point, 16 bit ints were actually processed using 32bit logic, which meant that the 16bit values had to be shifted 16bits in order to read into a register. 32bit was faster.

Re:Yes....

[Boronx]

Powerful hardware is cheap, but less powerful hardware is cheaper and more efficient.

I don't believe there is yet a $2 processor that can run Python.

These comments are off the mark

[Anonymous Coward]

The programming mechanism used is irrelevant to the contents of the volumes. When Tony Hoare introduced Communicating Sequential Processes (CSP), it was meant as a tool to reason about parallel computing. Then some misguided people thought it was about software, and that led to the rendezvous in Ada--a real setback.

Just buy the volumes, read them at enough depth to know what's in them, then they are a stupendous reference source. Need to know how to sort 7 items without a loop at lightning speed? There you go. Need an explanation why your program gets wrong numerical answers that make crappy graphics? It's in there. What's the best data structure and associated algorithms for your application? Help is on the way. Like others have noted, the hardback volumes actually wear out physically from use by people who must write the best software. Anyone can write crap after a short course at some for-profit "college", but if you want to be a star you need to know much, much more.

Yes I've read most of the original 3 volumes

[Anonymous Coward]

No there's no way I came anywhere near mastering all of it. I worked through some parts that were important general background or relevant to what I was doing, read through the rest well enough to have a reasonable picture of what was going on most of the time. There were some parts that were completely over my head but I learned a lot solidly, and a lot more well enough to have a wide overview and know where to look if I ran into that type of problem later. Someone who really understands everything in the books (I think it is doable) is more likely to be a mathematician than a programmer.

Some parts of the series are now pretty dated, like the original MIX computer (now replaced with MMIX), or the huge section of Volume 3 devoted to sorting and merging data using tape drives (yes, today "disk is tape", but it's different at that level). Many other parts are more of mathematical than practical interest. The math in a lot of it is quite advanced, "math grad student" level rather than "CS undergraduate" level.

There's what amounts to an abridged edition that's more accessible, called "Concrete Mathematics" by Knuth, Graham, and Patashik. It's also a good book. It's basically a more relaxed recap of the foundational stuff in volume 1, and the important parts of the other 2 volumes. That's a better choice for an undergrad CS class.

The whole series though is quite old fashioned by today's standards. These days the standard algorithm text is CRLS ("Introduction to Algorithms" by Cormen, Leiserson, Rivest, and Stein). Sort of an "old testament" vs "new testament" difference, if that makes any sense.

simple concept can be as complex anything

[globaljustin]

They're completely correct.

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"

Re:simple concept can be as complex anything

[smallfries]

The OP seems to understand the difference between easy/hard and simple/complex. There are more than two cases. The volume of detail has an affect on the difficulty of a programming problem, but it is not the same affect as when there are difficult details.

Re:simple concept can be as complex anything

[Anonymous Coward]

simple != easy. programming is simple, programmers make most things difficult. that doesn't mean the requirement was complicated, it may just mean the implementation was unnecessarily hard

Re:simple concept can be as complex anything

[globaljustin]

There are more than two cases. The volume of detail has an affect on the difficulty of a programming problem, but it is not the same affect as when there are difficult details.

I have seen other responses below that say the books are good for reference for what algorithm to use in specific and complex use cases.

I have only needed to "look up" an algorithm once (simple random sort in python to generate random work groups from all students present that day in a class I taught) but if you need to do that semi-regularly I can see the books being very useful.

As far as OP is concerned I still think it's just a matter of perception on the reader whether OP 'gets it' or not b/c their responses are so short on detail.

Re:simple concept can be as complex anything

[globaljustin]

simple != easy

I agree, always good to remember the two are different.

TAOCP

[woboyle]

Vol. 1-3 were my bible during my early programming career and they, along with vol. 4, have an honored place on my bookshelf. I still refer to them to this day, 30 years after I got the first volumes.

One does not simply read the Art...

[Anonymous Coward]

The Art of Computer Programming is not a book to be simply read, but a book to be acted on requiring years of work to following the programming and thought problems therein.

Used to be that if you found *any* error ...

[Anonymous Coward]

in the series that Knuth would send you a check for $2.56. Was quite an honor - many framed checks, few cashed.

Re:Used to be that if you found *any* error ...

[thestuckmud]

My check from Knuth, for finding an arithmetic typo in Vol. 2, is for the amount of $5.16 which includes accrued interest.

Regarding the original question: These books are fantastic, but they are challenging and the bit-miserly focus does not map well to today's typical programming needs. They are frankly too detailed and difficult for many readers. My advice is have a look at them and decide whether you need them to complete your life. If so buy the set and enjoy! If not, you probably won't miss them.

Just don't ask for mine. I'm keeping these books.

Just do whatever, and expose it to the internet

[raymorris]

> Programming isn't terribly complex. If you want to program, just do it.

You really, really should know better than that by now. In the 1980s, if you wanted to write a really crappy macro and use it on your computer, fine. Today, most software is exposed on the internet and runs on devices connected to networks that people depend on, networks that contain private information of one kind or another. "Don't worry about knowing what you're doing, just do whatever" is an extremely foolish approach.

Reference Material...

[ndykman]

The modern version is much more of a reference than textbook. While exercises still are part the book, it really for testing knowledge. Also, the field has just exploded and the task is really daunting. Satisfiability is an example, the current fascicle is 320 pages, but a more in depth look at the problem could run to twice that much and more. And there is new work being done on the topic every day.

Frankly, less and less programmers will need it, as it is easier and easier to create and use algorithmic libraries. Also, optimization just isn't what it used to be. Modern embedded silicon is quite roomy and complete control of the hardware leads to more problems (think buffer overflows) than it often solves. Finally, code that is verifiable is of more overall value, and so simpler algorithms and more constricted languages may be the future of a lot of code bases.

But, it's an awesome project and always will be.

Cover to cover?

[OrangeTide]

I don't think I've read any college text book cover to cover. I open up TAOCP when I need to get into the theory on a particular topic.

The value of Knuth's volumes...

[twasserman]

As a graduate student, I bought and used the first three volumes of these books when they first came out. At that time, computing resources were much more limited and much more expensive than they are today. Knuth's volumes made me appreciate the value of algorithms and the logical thinking needed to develop them. As a programmer, the turnaround time on submitting computing jobs to your computer center could be long, so it was in your best interest to exert some self-discipline and check your code carefully before pushing the card deck through the input slot. If you created software products, you had to create tapes (well before floppies, FTP, and email) and send them off to your customers, incurring manufacturing and shipping costs. So there was a significant financial disincentive associated with having to fix and replace buggy software. That's one reason why program updates were so infrequent, at least to the mid-1990s when downloads became more common. Today, it's relatively easy to build an app and make it available for download; if there's a bug, you can make the fix without extensive delays, and quickly provide an update at low cost, other than to your product reviews. My sense is that many developers would benefit from the more rigorous approach to programming inherent in Knuth's books, but I would also note that modern web and mobile applications are far more complex than anything that Knuth envisioned at the time, and that algorithms alone don't do enough to address the issues faced by today's full-stack developers working with a large number of software components and libraries.

Side note: Knuth's books predated electronic publishing and were typeset, necessitating careful proofing of the galleys prior to publication and many months of delay between completion of the manuscript and actual publication of the book. The errors made by human typesetters weren't always caught, which led to bugs in the published book (and in some of the algorithms and code). Knuth offered a reward of $1.00 to anyone who was the first to find and report an error. No email then, so you had to write a letter or make an expensive long distance phone call. Knuth actually sent out hand-signed written checks, but not many people cashed them, preferring instead to display the signed check as proof that they had found an error in one of these volumes. If you were wondering about Knuth's inspiration for creating LaTEX, this note should help explain that.

Re:The value of Knuth's volumes...

[countach]

The interesting part is he doubled the reward for every error found, and surprisingly he hasn't had to write cheques for much money the last time I checked.

Re:The value of Knuth's volumes...

[Anonymous Coward]

Fixing bugs is cheap these days. Finding them is still expensive.
That is why you want students to learn programming without fancy IDEs and overly helpful compiler errors.
When learning programming it is a lot better if errors hurt. Turn off that memory protection, a runaway pointer should lead to a reboot.
That is how you learn the disciple needed to avoid the errors that the fancy tools misses.

Re:The value of Knuth's volumes...

[pjt33]

The doubling was for bugs in TeX. Errata for TAoCP stayed at a fixed price, and he has written hundreds. If those had doubled each time, he'd be bankrupt.

Yep, and got pencil-signed copies, too

[kriston]

Back when I was at AOL in Vienna, VA, there was a bookstore called Computer Literacy Bookstore, a few doors down from the headquarters of Ringling Brothers & Barnum & Bailey Circus (who annually would show off their elephant-de-jour).

I bought the first two editions there the moment I became aware of them. They're signed in pencil by Knuth himself. The fact that he used pencil I found amusing.

I bought the third edition, which was a huge, huge event as it was much anticipated, and enjoyed it better than the first two since I have rather poor mathematical ability and could relate more to the fuzzy concepts of sorting and searching than some of the more mathematical concepts in the earlier two editions.

Since I left the software engineering community in favor of what we used to call "systems programming" and now call "DevOps," I didn't become aware of the "4A" edition until this evening. Thanks for the heads-up. Maybe it will encourage me to get back into software engineering and overcome my weakness in math.

Re:Yep, and got pencil-signed copies, too

[angel'o'sphere]

System programming has nothing to do with DevOps, or the time you did System Programming had a weird definition of it. System Programming != System Administration/Maintenance.

No.

[zenlessyank]

I did however read the Notepad help file.

Not much application

[countach]

If you're working for Oracle and coding the Oracle database and are looking for an algorithm to squeeze a bit more performance out of the engine, go ahead and buy the book, you might find something in there. But most programmers are using sets and dictionaries in their chosen programming language that has a decent implementation of algorithms and won't be helped by some algorithm which might squeeze a few more cycles out of the computer but nobody will reward you for. The Knuth book is for high fliers and hard core computer science projects, not for your average programmer.

Yes, most of the 3 volumes

[ihavnoid]

I started reading them around 2001 and went through the three books, a little bit at a time. Went through most of the exercises with 30+ difficulty, but couldn't really solve all of them.

A lot changed to myself - back then, I was a newbie undergrad programmer with undergrad-level math skills. Fast forward 15 years, I went through grad school and then couple of years of industry experience. My main programming languages moved from C++/Java to VHDL, then moved on to SystemC and SystemVerilog, and back to C++ with a bunch of bash scripts.

So, did I get to use the knowledge that I gained from reading it? Not much, I didn't even have to write a single data structure or algorithm because there are perfectly good (or at least, good enough) libraries for most of the issues that I had to deal with. Neither did I have a good usage of the math courses I learned (remember things like Laplace transformation or L-U decomposition?), nor did most of the non-engineering courses I took helped much. Still, all of them helped shape myself on understanding the world and helped gaining problem-solving skills.

Would I recommend it to other people? Depends, if you find your data structure and algorithm textbook easy enough and you want more challenging stuff, TAOCP is a perfectly good motivator to train yourself to solve complex problems. However, I think there are other ways to train complex problem-solving - e.g., a lot of advanced math/physics textbooks. However, for people who tend to fall asleep once they see those weird characters (and would rather live with pseudo-assembly code) TAOCP is a much better solution.

If you want to learn practical programming skills, then don't bother reading.

Yes, I have.

[aglider]

And You should as well. It would give you the right knowledge to understand the whys and the hows.

Re:I have read much of it, as I would an encyclope

[Anonymous Coward]

I only see him about once a year. He's still a sharp cookie.

His 22nd annual Xmas Computer Musings Lecture will be Dec 8th (auditorium seating is rarer than unobtamium for a talk by Dr. Knuth, but it is web-streamed).

Why not a survey?

[shanen]

As surveys go, it would be as good as most of the recent ones.

Anyway, I've never read even one volume of the series, though I'm pretty sure I consulted it at various times. It was certainly available in the university libraries where I was teaching or studying. Also I remember seeing it in the research library when I was supporting the researchers. However, I can't really remember any details after all these years. The place I should have been introduced to it was when I was earning my CS degree, but I don't think I even knew about it until afterwards... At that time I think I primarily associated Knuth with TeX.

According to my records, the only Knuth book I've read in it's entirety was Surreal Numbers , but I'm suspicious of my memories of that book... Did he construct an entire number system starting from the empty set? Was it based on a lunchtime conversation he had with a pure mathematician, and he basically reconstructed the discussion at book length?

Re:Why not a survey?

[shanen]

Just remembered another one. I think Knuth also collaborated on a textbook called Concrete Mathematics , which I purchased but never finished reading (so it isn't in my records). Pretty sure I gave it to one of my professors when I finished my last stint as a student...

Re:Why not a survey?

[pjt33]

Your memory sounds about right. For what it's worth, Dedekind constructed the real numbers starting from the empty set in the late 1850s, so that aspect of it has a lot of history. Knuth's book presented Conway's construction of the surreal numbers, which extend the real numbers with true infinities and infinitesimals.

I haven't read *through* it because it is a book t

[Anonymous Coward]

It's a book to be used as a reference when you need some depth in a particular subject. I refer to "semi numeric algorithms" quite often as an enginner implementing DSP. Kudos if you have read and understood the whole 4 tomes, but that was not the way Knuth is expecting one to use his book.

What about skip the programming?

[Anonymous Coward]

Have not read the books.. But why not just use platforms such as LiveBlox instead of spending a lot of time and effort to learn to program?

Re:What about skip the programming?

[Anonymous Coward]

Some of us are drivers.
Some of us are mechanics.
Some of us are designers.
Your approach to programming is that of a child.

Principia

[Anonymous Coward]

I've only skimmed TAOCP, but I feel like the mystique around it has more to do with its historical significance than being a real learning resource.

You wouldn't pick up learning physics from Newton's Principia (Feynman's Lectures on Physics might be a better start) but it could be worth reading to gain an appreciation for the process of discovery. For TAOCP, perhaps a newfound appreciation for typesetting.

Re:Principia

[meburke]

Well, I started out with a triple major in Physics, Math and Computer Science, but eventually dropped out for a while and became a Hippie. I didn't actually pick up my Physics from the Principia, but I did go to a Jesuit University and actually had to read it. I cannot adequately express how valuable this book has been to me.

Dean Kamen dropped out of school, went to the library, studied Newton's Principia, and went on to be an awesome inventor and thinker.

Eli Goldratt used the thinking processes in the Principia to turn USA manufacturing and business methods on their respective heads. Read his books, "The Goal", "It's not Luck" and "Critical Chain" for some really interesting examples of thinking. He wrote a terrific book, "The Choice" https://www.amazon.com/Choice-... which clearly describes how useful Newton's methods are.

Re:Principia

[budgenator]

I've read Goldratt's "the Goal", I was quite impressed at how he could relate a complex and dry systems analysis technique to an eighth grade reading level that was more entertaining than a lot of fiction stories.

Parts of it

[dcollins117]

It's not like a novel you read front to back. If you need an algorithm you look it up.

I had to write a math library for a DSP that didn't have compiler support yet. TAOCP came in handy then. The parts I did read I went over again and again and once again. It wasn't fun by any means.

Re:Parts of it

[computational super]

It's not like a novel you read front to back.

Must respectfully completely disagree. I'm halfway through volume 2 now, trying to work (or, at least, attempt) all of the exercises, and I can't imagine that I would have gotten anything from this series if I'd just treated it as a reference work. If I were to go look up an algorithm, I'd find that its description relied on (and back-referenced) some mathematical concepts that were covered in earlier chapters, and that the example code is written in MIX which itself was covered in a long section around the middle of volume 1. So you'll end up reading most of the book anyway. Further, there are important insights into the details of the algorithm that are covered in the exercises which you'll only really internalize if you work through the details yourself.

No...

[gweihir]

Interestingly, despite being in CS for now 30 years and doing some quite algorithm-intensive and complicated work even today, the only time I consulted them was for an exercise in CS 101 that referenced something in there. I have always found easier to read and better references, quite a few of them research papers. Don't get me wrong: I think it is good that they exist, but they are more a reference for fundamental research than a handbook for an engineer or applied scientist.

Partially

[Anonymous Coward]

I never read TAOCP properly, doing all the exercises, following all the proofs, etc. But I very often use it as a reference - especially when I need to make a *hardware* implementation of an algorithm.

Plot too thin, just like a dictionary

[bugnuts]

I have the first three, and I have read parts of all of them. Especially "Sorting and Searching".

It's reference material. You read it when you need it to get a much (much) better understanding of what you need to do to solve a problem. That's the point of reference material -- you don't have to read it except for the parts you need. That leaves your brain free to think of important things, like where you left your coffee cup.

Absolutely!

[meburke]

In fact, I keep re-reading parts just for the imaginative spark.

OK, I admit to being an assembly language addict. I think describing tasks in machine language is as stimulating as a book full of logic puzzles. (But let me still recommend ANY book by Raymond Smullyan, such as, "The Lady or the Tiger?" https://www.amazon.com/Lady-Ti... )

I also admit to programing in LISP and using Jan Lukasiewicz's notation for symbolic logic.

I suppose you should keep these things in mind while evaluating my recommendations.

Yes,but it's not about Computer Programming

[NReitzel]

These are books about algorithms. I've read them all, and worked the problems.

At the risk of exposing myself as an elitist snob, I wonder about the people who don't think one has to understand the basis of an algorithm, and what makes for an algorithm as opposed to a heuristic.

Decades of research went into understanding how computing machinery accomplished the things that they did. A certain Bill Gates came along and decided none of that highbrow stuff applied to the new paradigm of PC's. That's one of the reasons that we had fifteen years of the worst memory manager on Earth, in Windows. In point of fact Knuth talked in detail about this memory management as a counterexample of how it should not be done. But it was simple amd worked on PC's and hey, memory is cheap.

Knuth's books are about the Fundamentals. They're not practical guides and they never were practical guides. They are insight into how a certain variety of stochastic machine operates and the kind of things one must think about to design proper algorithms that work all the time, as opposed to work most of the time. They are the Zen of computer programming, a philosophy of thought and a discipline for creating algorithms. This is not how to write code.

It certainly isn't for people who confuse how to speak a language with how to converse.

Yes some of it

[Anonymous Coward]

No one is going to read the whole thing, there's no reason to. You only read the parts that you need to work on. Some of the material doesn't exist outside the book and is referenced by other works. It's a true compendium of computer science and you can't call yourself a serious programmer without keeping a copy nearby that you can flick through. Think of its as an extremely well written encyclopaedia. I just ordered a physical copy since I was working off scans. It's on sale on Amazon, don't hesitate to buy it if you have the room for it.

TAOCP is a great reference, I still often use it

[fgrieu]

I like TAOCP, a lot; mainly, because the material is so coherent, precise, well justified, and understandable enough. I spent many weeks reading sections of TAOCP; especially volume 2, on Semi-numerical algorithms; my copy has several post-it marks on techniques useful in my field (applied cryptography): wide multiplication algorithms, modular arithmetic including exponentiation, statistical tests.
I also had significant uses of volume 1 (Fundamental Algorithm), which covers things such a tree, and hash tables; even purchasing the third edition, on top of the second.

That said,
- _reading_ TAOCP from start to end is not something to consider lightly; perhaps if one has a year to spend.
- I never caught on the use of MIX in some programs; I just skip this, and advise contemporary readers to do so, even if that's missing a part of the beauty.

More of a desk reference than a novel...

[rgbatduke]

As many above have pointed out, there is little reason to read the entire series "like a novel" from cover to cover, in addition to the fact that yeah, it would take a while to WORK through it like a textbook as opposed to read through it quickly to see what is there. And yeah, there are better books now in profusion on many of the topics covered, although AFAIK there is no book or book series that is as encyclopedic on the subjects he covers.

However, many people will find some of the sections very useful. I personally found "Seminumerical Algorithms" useful indeed when learning about random number generators and testing random number generators. It isn't the last word, and it certainly isn't the latest word as we move into a 64 bit world and beyond, but it is an excellent starting point. In other parts of the series there are other gems or nuggets well worth studying or reading, even if you move on to actual research papers or better books afterwards.

To sum up, it is a useful thing to own if you are doing a lot of very widely spread code development and need to acquire literacy quickly in subjects it covers, even if you are going to end up looking for an O'Reilly text on some of those subjects to get a more modern perspective. Those OR books are probably going to reference, rewrite, and augment Knuth.

Note well that I'm an Old Guy (tm) and actually did write a lot of code in Fortran once in the long ago before abandoning it for C and Unix and beyond. TAOCP was one of the ONLY really good encyclopedic references for people who were NOT CPS majors and who needed to learn about algorithms of one sort or another or some aspect of coding covered in one of the many CPS courses they never took. They (I) didn't need a course with the best textbook of the day -- we needed to get started. Once started, we knew how to learn and go beyond the start. 1.5 cubic feet of shelf space wasn't too high a price to be able to learn something about everything or anything to get started.

Read and Programmed using the ASM

[Anonymous Coward]

In college at UCSD, about 1978, we not only read these books we used the assembly language to write real functional programs, run on the mainframe, on which we were graded.
The professor once got himself into a corner trying to give an example using the language, and after several attempts to correct it on the fly on the chalk board (yes, real chalk) he made it a homework assignment due the following week.
Are these worthwhile books? I'd say yes. Using them as reading and actual homework made everyone in the class sharper when we moved on to the real world jobs after college. You knew and understood the basics, and since you knew how the algorithm ran at a fundamental level, you knew how to write tighter code.

Frankly, it's not practical

[Kartu]

Using books as a list of algorithm references- sure why not.
Studying these books line by line is a monumental effort which is hard to justify, if the only thing you are after is coding.

Re:Frankly, it's not practical

[Bengie]

Reading books to gain technical knowledge is a wasted effort. Knowledge can be trivially gained by simply searching the Internet. I read books to gain wisdom. I want to change how I think about programming.

Nyes I did(n't)

[Anonymous Coward]

I got all of them. Yay! And they are all mostly good. It's fun to know what algorithms exist out there for a problem, it's fun to know why something is good or not. The abstract part is awesome. And it helps hone your instincts whether somehting makes sense or not by having good litterature in your subconscious mind.

But then, the algorithms are incredibly generic. They are also complex, but generic. These are "solved" problems, with a really great academic solution, that might or might not apply to your day-to-day life. And usually, someone took the time to make such algorithm and improve upon it by multiple optimizations related to day-to-day operations instead of a conceptual idea.

These books algorithms don't (all) dwell in modern optimizations, multithreading, multitasking, pipelining, locking. They don't answer questions people have on a particular nitpick they might have. But they do help give a generic and very potent algorithm for you to start looking upon, all of this in beautiful books. And like all education-based books, alas, the most complex of issues are "left to the reader". Yeah, that's the most complex of topic (the one you're looking for) and they just say oh yeah, have fun. I hate that crap.

Now, today, we have libraries and libraries and libraries, open source this and that, online papers for the latest greatest, stackoverflow for day-to-day. And there are specialized books for specialized topics. I once bought a book that answered all the most complex questions with C implementation. That included creating a B-Tree (which is usually left as an exercise after explaining the concept). Now I am the proud owner of a Leaf-data B* Tree I created myself. That wasn't brushed adequately at all in Knuth books. Another book took a hundred pages to explain all the intricacies of userland/kernel/vm/chipset memory management, and due to some time I had to take working with a horrendously subpar slowpoke error-prone memory algorithm on an embedded device with 64MiB of RAM, I wrote my own alloc library with exactly the requirements I was looking for (mostly a multilevel buddy system with 4-byte header per block and 2K of data header alongside an embedded headerless bucket allocator for tunable =16 bytes allocations with O(1) operations 99.9% of the time and the .1% being not thread-locked and very short). That's not starting to be brushed at all in a general compendium of algorithms.

So are they relevant? I haven't even looked at them for the past 5-6 years I'd say. But they gave me what they had to give: insight on complex problems and ideas for solutions if I ever had to go there. No need to understand every single proof line. I am just glad I grew up with them.

Read the first 3 a long time ago

[Anonymous Coward]

I read the first three in their original incarnation.- the two that had the deepest impact were Semi-Numerical Algorithms and Sorting and Searching.

The code in pseudo-assembler wasn't easy to read, but I coped. I believe he completely reworked that in the new versions of the first three books before starting on volume 4.

I haven't read the new versions, but I'd recommend them over the originals to a newcomer.

Re:Read the first 3 a long time ago

[computational super]

I believe he completely reworked that in the new versions

He plans to, but hasn't yet. The current edition of the first three volumes (the third) still presents all of the examples in MIX. Volumes 4+ are written using a more modern MMIX.

Have used the books as a reference numerous times.

[Anonymous Coward]

I have the books in question on my bookshelf. I can't say that I've worked through them, but I have used them for reference more than a few times through out my career though. I usually end up using them if I need to know the little details on an algorithm, it's not that often, but they are a real life saver when you really do need the detail.

It has been a while

[Diss Champ]

But the first three (all I have read) are excellent. Yes, it takes time to work through. But it is worth it. Knowing what has gone before helps in figuring out answers to new problems. Knowing whether something is a new problem saves a lot of time.

I keep meaning to jump back in and catch up.

Yes.

[tietokone-olmi]

Of course.

And I won't be sending any resumes to Microsoft, that's for sure.

I hired a developer once...

[Anonymous Coward]

The interview went well, several managers in the company wanted to hire him and the choice was his. He choose my group. He quickly showed himself as a superstar.

After he had been on-board for a while he asked if I knew why he choose me. It was because I had 3 volumes of Knuth and 6 volumes of the computer programming series on my bookshelf.

I was embarrassed to admit that I hadn't read them, he said it didn't matter, I had them and that said all he needed to know.

After that I started Knuth but didn't last long.

I'm no longer there but last I heard he was in middle management. Smart guy.

Yes Buy them and study them

[Anonymous Coward]

If you have as CS degree and are not familiar with Kuth you should ask for a refund from your school.

No. don't be silly.

[Anonymous Coward]

Like the majority of my college textbooks, the bookmark in the first volume is at page 20.

I really, really will get back to it sometime. Honest!

Now that I've retired I have better uses for my oh-so-valuable time.

Catching up on 'Mythbusters'.
Throwing out 30 years of junk we have acquired.
Frequent naps.
And my all time favorite: sitting around and doing nothing other than listening to my arteries harden.

Writing a Ph.D. dissertation is easy.

[Anonymous Coward]

It's convincing a review panel that it is valid is hard.

Re:Writing a Ph.D. dissertation is easy.

[luis_a_espinal]

It's convincing a review panel that it is valid is hard.

And you will have a hard time convincing them if the dissertation was not written with sufficient academic rigor and quality.

Re: Writing a Ph.D. dissertation is easy.

[Anonymous Coward]

..or if the panel's members don't like the fact you're smarter than they are.

I read parts decades ago

[Anonymous Coward]

I read V1 and figured out that I'd re-invented a bunch of fundamental searching and sorting algorithms like hashing and trees. Sigh.
V2 and V3, I just skimmed and cherry picked for help with specific problems.
I don't have V4 and 1-3 mostly gather dust these days.

The books are somewhat dated a checkpoint in time of the state of computer algorithms.
They don't contain later discoveries like B-trees or red-black trees.

For someone with an understanding of under the hood computing, they shouldn't be especially hard to read.
Preventing re-invention makes reading a compendium of algorithms for the areas you work in necessary.
These were well done in their day, but seems there should be a more up to date these days?

eternally incomplete by definition

[Anonymous Coward]

He hasn't even started volume 7 on APPing APPs in APPOS 10.

Re:eternally incomplete by definition

[Ed Avis]

http://knking.com/recbooks/ima...

Once

[luis_a_espinal]

Have You Read 'The Art of Computer Programming'?

Once, when I was in grad school, and I kept plowing through them for a year or two after I left. I still have them somewhere in the attic. I wouldn't do it again, but I would recommend any one in CS to give it a shot. It is a good exercise (just as it is a good exercise to try at least some parts of MIT's SICP.

I wouldn't use them as a reference, though. For that, I hit CLRS, Algorithms by Sedgewick or O'Reilly's Algorithms in a Nutshell.

Qubertino

[snookiex]

TAOP will make you a programming demigod as much as reading The Art of War will make you a warlord.

Certainly!

[kschendel]

I've read the 3 initial volumes, and they remain a useful reference. I don't need to look there often, but when I do, TAOCP is the best reference I own.

I don't pretend to have read every word, of course. Some of the stuff on random numbers is only of mild interest, I don't really care about tape sorting, etc. I've skimmed nearly all of it, and read maybe 1/4 to 1/3 of the text in detail.

I've not yet ventured into Volume 4, although I think I'll want to do that sometime reasonably soon.

DK-impervious = DK-permeable

[epine]

One of the most important things is knowing when you don't know enough.

TAoCP is a never-fail personal Dunning–Kruger removal tool.

I never finished the mathematics degree I once started, but I always found the larger concepts easy enough to understand when sitting beside a real mathematician.

I certainly would have difficulty completing most of the HM exercises (this despite also owning Concrete Math). I rarely have difficulty understanding the form of the solution if I cheat and look it up.

Another book I'd put into the same category, roughly, was the original Applied Cryptography where it ought to be far more obvious that one shouldn't naively roll one's own, but somehow, for too many DK-impervious DK-permeable programmers out there, it isn't. (I'm looking at you, Wi-Fi Alliance; and every idiot who ever used the speedy MD5 to hash a password database, with or without salt, or worse.)

There's little wrong with Knuth's exposition that actual competence wouldn't fix.

You do the math.

That old graybeard.

[Anonymous Coward]

He has nothing to teach us. He should just go hide under a rock and let us new and intelligent software designers take over!

Beautiful Books

[Dr. Bombay]

I read the three volumes in college. I was a chemistry major, so this was all my own doing. I had built an eight bit computer in high school, a SWTPC 6800 machine. During college I became an assistant sysadmin on a DEC system- 10 minicomputer in one of the chemistry professor's lab. I still have to this day a deep interest in both chemistry and computers. These three volumes were the basis of my informal computer science education. (My formal education resulted in a Ph.D. in Physical Chemistry.) I was especially intrigued by the sorting algorithms and coded several of them in different languages for comparison of their operation.

The books are a fine examples of mathematical typography and I became an early adopter of Knuth's typography software TeX and Lamporte's LaTeX. I was the first person in the UIUC chemistry department to digitally typeset their dissertation and print it on the department's laser printer attached the the VAX-780. I investigated WEB (the self documenting language that TeX is written in) as a possibly useful programming tool, but found it to be much too cumbersome.

Others in this thread have commented on how miserly the algorithms are in their use of bits. The powerful processors and gigabytes of RAM available in desktop computers and even some portable devices can lead to bloated and sometimes inefficient programs. With the increasing tide of IoT devices with limited computational resource and available power, a miserly mindset can lead to more functional programs and better battery life. Even GPU programming lends itself to being miserly in the use of resources.

This set of books is not something to read to learn how to program. These are the volumes you read to become a craftsman and more than just competent at programming.

Nearly all

[Anonymous Coward]

I read all of the available volumes (1, 2, 3, 4a) in my University's library.
The first thing that I noticed about them was that they were nearly unused despite some of them being there for several decades.

Now we should distinguish between reading, understanding and working through the exercises.
I had little time while reading them so I could not get everything to 100%.
I would say that I understood about 3/4 of what I read and that I actually did less then 1% of the exercises but I worked through the solutions of about 10% to understand what it takes.
If I had more time, I would go back and work through more of them on my own in the language of my choice.

Now what has reading this books done to me?
Well, the itching got worse but on the plus side I would say that they gave me a broader understanding of CS.
Although I began reading them about five years ago, I have been using concepts that I first learned from those books about twice a year.
I reread some parts of them for reference several times and I think this will continue.

I feel that a modernization might be a good thing to do, although I cannot imagine a person that has the knowledge and endurance of DEK *and* still has free time for that.

Too Expensive...

[RealGene]

$60 for the Kindle edition? It's hard enough to slog through without having the nagging feeling you're being milked.

TAOCP Saved Me

[Anonymous Coward]

I read 1/2 of volume 1. The remainder is on my bookshelf. I have used snippets to help in my studies. I found an example in the combinatorial volume that helped me on an assignment in my algorithms course. The Internet was completely useless, TAOCP captured the knowledge succinctly.

It goes to show that well prepared books are still beating the Internet for knowledge archiving (although, Google scholar may have extracted the passages, I still admire the work Knuth accomplished here. An incredible feat and a wonderful person. Huge fan.)

I use it as a reference work.

[mellon]

It's hugely useful for that. You can read it in snippets. Reading it as if it were a novel would be about as smart as reading a dictionary that way--not necessarily a terrible use of time, but more of a slog than the average geek is going to be able to manage.

Status symbol

[Anonymous Coward]

I found the first 3 volumes far too abstruse to be useful - or perhaps "to be practical" would be the better phrase. I don't think that the concerns of the modern software design team are well handled in it. It's kinda the War and Peace of the CS world - you definitely want the (5) volumes on the bookshelf in back of you for your resume/PR photo, but as far as reading it? Not so much. I think it's more to be recommended for historians of CS --although there are plenty of comments from those who claim to be using it. The range of jobs and educational backgrounds are so broad, I don't think there's any one neat answer to the question.

Just hell

[fyngyrz]

You're just nybbling away at the parent's ego now.

Its irrelevant these days

[JustNiz]

Its irrelevant these days, since commercial programming is no longer an art.
Programming used to be an art. Art implies using innate skill to create something intrisically elegant/beautiful and mostly intended to be around for a while. Since this book was written, most institutions have done all they can to remove all creativity from programming, turn it into a braindead dumbed down repeatable process so companies can get away with hiring even the cheapest most clueless people to write software. Ive seen time and time again that there is no reward or recognition for writing elegant, stable code.
All the rewards/recognition goes to those who bodge together a quick unstable hack not suitable to be maintained or to last longer than the 10 minutes required to convince the boss to check the "done" box. They move on after blowing their own trumpet and leaving a "TODO: rewrite this" comment for other more careful people to find and repair their damage. But the managers don't see that part.

machine code ate my neurons

[fyngyrz]

But can you program in Z80 and 6502 machine code?

Yes. But more importantly, I can program in 6809 machine code. Including building all the index modes. Which, back in the day, is one of the things that saved me from having to design in, and then program, CPUs like the 6502 and z80, both of which are seriously anemic by comparison. But I prefer to program in assembler. Because I'm sane.

My affection for the 6809 ran so deep that I wrote the 6809 emulator you'll find here, which required me to implement the entire instruction set from the ground up.

But yeah, I can write machine code for about 10 microprocessors. And you know what? In the day... that was useful. I could read (E)(P)ROM dumps, I could cold-patch... but today, I just wish I could get the brain cells back. :)

Not quite dead yet

[fyngyrz]

It means that we are now far more removed from access to the metal to even do a lot of the optimizations that we've done in the past.

Well... no, it means that you are, perhaps. Some of us still write in c or c++, and keep our attention on the details. You can tell you've run into one of us when the many-functioned app you get is a couple megabytes instead of 50, runs faster than the fat ones, and doesn't suffer from black-box bugs inherited from OPC.

I always thought that the user's CPU cycles and memory were things a developer was obligated to treat as the user's valued resource, and so not things to waste.

I know, totally out of date thinking. It's ok, I'm old, I'll die soon. :)

On Logic [Re:Hell no]

[Tablizer]

Nah, not really. It just requires logical thought.

Not necessarily. For one, you should make the code readable by a typical developer, not an ideal developer. You cannot control all future staff. That means you have to try to think like a typical developer, not an ideal developer, and that may exclude ideas that are "logical" to you.

Second, having a feel for how things tend to change over time helps one design code that is better able to handle future changes (fewest code changes and disruptions). That often requires experience in both coding and the domain at hand, and a feel for how and when fickle managers/customers change their minds.

That's not direct logic, per se, but a combination of general experience, domain experience, and experience in human nature.

I wish it were merely about logic. Life would be easier, especially for us nerds who tend to have sub-par people skills.

Re:On Logic [Re:Hell no]

[Bengie]

Not necessarily. For one, you should make the code readable by a typical developer, not an ideal developer. You cannot control all future staff.

I work on problems that require an ideal developer just to understand. A problem cannot be simpler than it requires. To simplify it any further would mean you're not solving the problem anymore.

Ironically, sub-ideal programmers are illogical. You are effectively saying one should write illogical code. I have only met two kinds of programmers. Ones that get lost in their own code and need me to help them debug their problems, or programmers who can debug their own code and think very similarly to me. I see programmers who follow every best practice, use the best pattern nearly every time, and write beautiful code, but their code is still shit. It's brittle, it is difficult to debug, it benchmarks fast but is slow a molasses when hammered in prod.

For some reason people chalk this up to "programming is hard and systems are complex". It's really just "problem made harder than it needs to be". It's like looking at a fractal and saying it's complex, when it's really just a simple algorithm.

I forget which "worshiped" programmer said it, but they said they would rather work with a programmer who used every anti-pattern but was intuitively good at programming than a cargo-cult programmer who perfectly used every pattern and best practice. The former will always produce a better product.

Re:On Logic [Re:Hell no]

[Tablizer]

and think very similarly to me.

You might be mistaking your own way of thinking for universal logic. Without specifics it's hard to know.

Ones that get lost in their own code and need me to help

If that's true, that's real problem. I can usually read my own code just fine because I know how I think and have a certain code-writing pattern that is logical TO ME. But other coders often don't agree. I try to figure out why by asking a lot of questions, but it seems to come down to a personal preferences in the end.

On the other hand, if they cannot read their own code because you or the org dictate a certain style that is awkward to themselves, the issue may be a different matter. What's "logical" or "simple" is often in the eye of the beholder: I've been in long and winding debates about what "good" is, and it's like politics: you encounter fundamentally different ways of viewing life and "base" rules of scoring.

But, there may be some value in having a shop of like-minded individuals. Even if the "standard" is arbitrary, at least it's consistent among the team. The down-side is that it's harder to find replacement staff because more filtering is needed to find another "mind match". I've been through a lot of interviews, and that's essentially what's going on: they are seeing if one is a "good fit" for their org's style.

Re:On Logic [Re:Hell no]

[Bengie]

You might be mistaking your own way of thinking for universal logic. Without specifics it's hard to know.

I really wrote that horribly. I didn't mean "just like me", it was more of an abstract concept. Here is one example of what I am getting at. I regularly get hit from other programmers to help them and they will say something like "I am getting this result, but if I change this, I get a different result, which result is correct?". Really, this is a WTF moment to me. I really want to say something along the lines of "do you even understand what what your code is doing?!" This happens allllll of the time from so many different programmers. Sometimes they'll be stuck for days and I'll see a group of them gathering, I'll wander over, asked a few questions and the problem will be solved. Sometimes explaining the issue causes their eyes to glaze over.

I have had to work with other programmer's code where they had completely differing ideas about how to solve a problem and they have completely different coding styles, but their logic was consistent. I was able to easily read their code. Same thing for them reading my code. I guess that what I was getting at all along, "programmers like me". My problem is most of us that think alike get stuck on solo projects and rarely get to interact with the team, and our code typically just works well because we think of the corner cases ahead of time, so no one else gets to look at our code. It really sucks. I really love peer programming because I get to learn other ways to think about problems.

The code I typically get to see from other programmers usually makes me want to claw my eyes out. Following best practice and what-not, but the logic behind it is fubar. Somehow most other programmers see this code as great code, but that's why they all group together stumped on problems they can't figure out.

If that's true, that's real problem. I can usually read my own code just fine because I know how I think and have a certain code-writing pattern that is logical TO ME. But other coders often don't agree. I try to figure out why by asking a lot of questions, but it seems to come down to a personal preferences in the end.

Exactly this case, not the later. I work with a lot of complicated problems, like integrating hundreds of different systems from 3rd parties where you need to transform the data in a way the other systems will understand, but at the same time, almost none of the systems follow their own standards very well, so you need to read between the lines and infer what is actually meant by the data. This is a very hard problem, hard enough that Microsoft and Google have come to us for professional consultation because they heard we're the best.

Re:On Logic [Re:Hell no]

[Bengie]

I should have mentioned, the teams are free to choose their own coding styles for their projects. Only the public APIs adhere to a mostly company style. I would rather read messy logical code than clean illogical code. I've seen the extremes.

Re:On Logic [Re:Hell no]

[Tablizer]

Maybe they need to learn or be taught how to break their code or logic into smaller sub-sections. They may be biting off chunks bigger than their brain can digest and get themselves into knots.

Maybe also teach them to create "trace codes" that document the logic paths a result took. Append them to a string that can be used for debugging. For example, if an amount is chopped because it exceeds State Law X's max, then append ",state-law-X-max" to the trace string so that they can know that particular rule was triggered in producing the results. I do this myself if there are a lot of potential business rules in between a result. Very helpful.

If it doesn't hurt performance much, even store the trace strings in the database result(s).

Re:On Logic [Re:Hell no]

[Bengie]

Very possible those are some of the issues, but many of the people I am having issues with are some of the best in the industry, skill wise. They came with great recommendations and have many years of experience. They are skilled, but not talented.

Moret and Shapiro

[angel'o'sphere]

My preferred book is: https://www8.cs.umu.se/kurser/...

I basically bought it because it is a superb hand craft (I mean cover, paper and print).

The contents is an easy read. When I bought it, it was the most expensive book I ever bought ...

To sad that the announced second volume never was published.

Yes...but not very useful in my career

[CAOgdin]

I still have Volumes 1, 2 and 3...gathering dust.

I first started programming in 1962, on IBM 1401 (dearly loved it's variable-length memory management) and IBM 704 (briefly, before it was replaced with a 709, then the 7090). I used to take a massive printout of the IBSYS operating system for the latter to understand how real people wrote code to achieve an outcome; that was back when programmers still felt it was essential to write comments to explain what/why that specific code was there, and its' purpose). At the same time, I was a junior member of a group of "code sharers" at C-E-I-R; we evolved a punched-card deck for the IBM 1401 that became the basis of every program we subsequently wrote (I ran into the deck, called "CELIB"--for CEIR Library--several years later in a consulting gig in Australia, where they'd been using it for more than a decade after originally getting as part of a contract delivery...which my name in some of the comments). I was also engaged in running huge "linear programming" models on the 7090, such as one that forecast the likely economic consequences to the U.S. of removing the tobacco industry (i.e., abolishing the manufacture and sale of products), but the code was written by my more mathemathically endowed superiors, Eli Hellerman and William Orchard-Hays and you may know it as LP90, which was posted to the SHARE library at IBM; I just wrote some utilities.).

So, by the time Knuth published, I was an experienced programmer, and I devoured his books with interest. Like many programmers and professionals in allied fields, there were lessons to glean (like, "Wow, that's clever," or "Hmm, that's an interesting way to look at that problem"). I'm sure they influenced me, but it was not a "cookbook" to me. After I read them, they went on a shelf, and moved from home to home, and they still reside in a prominent place on my bookshelf, but gathering dust.

Programmers, today (especially those under 35 years of age) seem to eschew the idea that anybody else's code could be educational, and I find that an odd and juvenile approach to the world. We must stand on the shoulders of giants, and I still, to this day, learn new techniques and insights (and folly) in others' code. But, I got here (now aged 75, and still writing the odd bit of code; even CMD language) by learning from others, for no ONE of knows as much as ALL of us.

My take on it

[david_thornley]

This is difficult to answer, since TAOCP is tied in with my early education. I went through all three volumes more than once, although I never solved all the problems. (The third exercise is to prove Fermat's Last Theorem. In my copy, it's listed as difficulty HM50 (HM for Higher Mathematics, 50 was a major large-scale research project on his more or less logarithmic scale), and I've heard it has been demoted to HM47 in later editions.).

A lot of TAOCP is excruciatingly detailed analysis of stuff approximately nobody actually cares about anymore. Some of it is completely inapplicable nowadays, such as exact timings of programs. The half-volume on sorting is primarily concerned with in-memory and tape sorts, for example, and the intricacies of different sorting methods with multiple tapes are of no use today. In the original three volumes, everything was single-threaded, although coroutines were in Volume 1. There are good algorithms books nowadays, and I don't remember any but TAOCP back then.

Most of TAOCP is of little practical use nowadays. Pretty much everything it covers is taken care of in libraries in modern computers (or even in hardware, such as floating-point numbers). There's much that's useful for someone who wants to understand how the libraries do what they do, or even create one. I used Volume 2 as the foundation for my entry into a programming contest to do 32/64-bit multiplication and division efficiently on a Z80 (about the only time I used the dual register banks)..

What I gained from it was partly fundamental education and deep understanding and partly mindset. I can't honestly say what anyone would get out of it, although I'd suggest anyone who's interested in what's underlying what they do read part of it and give it a good shot.

Can't prove verifiable facts I use wrong?

[Anonymous Coward]

See subject: If anyone is the lunatic here, it's clearly you. My ware is not a malware & I have tons of valid verifiable reputable sources proving it here https://ask.slashdot.org/comments.pl?sid=9954349&cid=53422667 and apparently you're all out of "downmod points" to try "hide" that, lmao... you lose!

* BUT, that's what you always do, don't you? Yes... lol!

APK

P.S.=> Stalking me around & trolling me by unidentifiable anonymous posts with your libelous failed attacks on me only proves my points all the more - thank you for being SO stupid in that... apk

Google It!

[Anonymous Coward]

Other than to impress people who only looked impressed and secretly think your nuts to have them on your bookshelf.

If you have a question Google it! Odds are someone somewhere has faced a similar issue and has come up with a solution you can borrow, use, steal..

Christmas Lecture on Dec 8, 2016

[Doctor-R]

Knuth is giving his annual Christmas lecture on Thursday, Dec 8, 2016, at 6:00 pm PST in the Huang Engineering Center's NVIDIA Auditorium. It will be webcast. See: http://www-cs-faculty.stanford... All of the previous lectures are online.

Volume one was my textbook for Algorithms many, many years ago, so I read it. I read volumes two and three when they first came out. I read some of the bits of volume four A. When I read 1-3, they were the best or only sources of their content. One of the key features is the use of assembly language for a mythical computer (later revised to be more RISC-like). i wrote an interpreter for MIX for my computer architecture class. Possible programming languages in the 1960s were FORTRAN, COBOL, ALGOL-60, IBM's PL/I, and IBM-s APL, and compilers did not optimize. The obvious real computer architecture to use was the original IBM 360 instructions set (Principles of Operation). Choosing any one of those would obsolete the books in five to ten years after publication.

My fantasy is to publish the draft of the original two volume Art of Computer Programming, started in 1962. When he started rewriting it, he planned for seven volumes, which are outlined on the end papers of the published volumes. The two volume original is a snapshot of Computer Science in the early 1960's.

I would like to read it

[Anonymous Coward]

when it's all finished, and available in digital format.

I have even more vs. your troll bs

[Anonymous Coward]

See subject & https://ask.slashdot.org/comments.pl?sid=9954349&cid=53422587/ downmodded unjustifiably 1st! Here's more:

I support APK's stand on the hosts file by Trax3001BBS

Your premise that hostfiles are a good way to deal with advertising and malvertising is quite valid by JazzLad

No complaints from me, I like APK... Reminds me to use a host file. Also, his stuff is free by aaaaaaargh!

APK's monolithic hosts file is looking pretty good by Culture20

APK... Awesome to see he's still spreading the good word by Molochi

ABP is insufficient as a solid hosts file does everything that APK reminds us about by fast turtle

APK isn't wrong by cfalcon

APK, I know people give you a lot of shit regarding hosts, but please don't ever stop by nasredin

You need APK's hosts file by Teun

APK solution STILL relevant by Thud457

you're right about hosts files by drinkypoo

APK

P.S.=> Want more? EAT YOUR WORDS while stalking me by unidentifiable posts loser... apk

Zontar you can't ever be as good as me

[Anonymous Coward]

See subject: 1st take your meds mentalcase https://slashdot.org/comments....

&

I see you're also a druggie too https://slashdot.org/comments....

Going to make more sockpuppets to stalk & troll me with you loon https://slashdot.org/comments.... ?

+

Your sending me postcards with threats too https://slashdot.org/comments.... ?

* You're a butthurt loon freak, plain & simple... you did it to yourself, loser.

APK

P.S.=> Still trying to live down how I shot you to pieces in the art & science of computing Mr. Butthurt https://slashdot.org/comments.... ?

How about proving hosts & my program that builds them are useless too https://slashdot.org/comments.... ?

See subject above - They're FACT & your fails made them so, lol!

(I've done all that LONG ago & you haven't done squat of note... must hurt like hell, that truth, or you wouldn't be stalking me like the loser druggie mental loon you're proven to be in YOUR OWN WORDS in those links above, lol)... apk

Re:Zontar you can't ever be as good as me

[Anonymous Coward]

Zontar owned your sorry ass ages ago and everyone knows it.

Don't go away mad, "AlecStaar," just go away.

Re:Zontar you can't ever be as good as me

[Anonymous Coward]

Doesn't look it from apk's post you replied to. It's completely vice a versa. Apk pwned Zontar the sockpuppeting troll.

It's rough going

[pugugly]

I made it through V1 and half of volume 2 a few years ago, and found myself frustrated.

For myself, Godel Escher and Bach feels to me to be more useful as a programmer mindset book (or is that just me) or Unix Power Tools for practical guidelines,

And yeah - a lot of it is above my level of mathematical sophistication - I topped off at modern algebra, and I concede I fin it frustrating that I can have a reasonable grasp of number theory, encryption, and matrix arithmetic, and still be going "Wait, whut?" in these.

Required text in college. Read 1-3.

[DutchUncle]

It was the best comprehensive collection of information at the time it was published, and it's all still valid (if somewhat dated as far as specific examples). What has changed is the tradeoffs and power of systems. If you're not doing tiny/cheap embedded applications, you don't care about economizing quite as much. OTOH the concepts of algorithmic complexity are even more important than before because of the huge scale of online systems.

old times

[Anonymous Coward]

We actually used the first two volumes in my computer science classes some years ago. Computer languages and GUI frameworks come and go - mathematics is forever. I actually needed to use Euclid's algorithm (circa 300BC) in a program and Ada Lovelace's method for computing a Bernoulli number on a mechanical computer no less is just as valid as the day she wrote it.

Is it still relevant?

[SoftwareArtist]

I've occasionally thought about reading it, but one of the things that always stopped me is doubts about how relevant it still is today. Could you comment on that?

This book was written when computers only had one core and multithreaded algorithms weren't a thing. When there wasn't such a thing as vector units, to say nothing of massively parallel processors like GPUs. When performance was entirely determined by computation, whereas today it's often dominated by memory access. The factors that go into designing a good algorithm today are really different from what they were in the 1970s.

Even aside from that, there's been a lot of progress since then. Maybe it's a great reference for 50 year old sorting algorithms, but there are better algorithms known today.

Re:Is it still relevant?

[guruevi]

It depends on what you're trying to do, it sure isn't going to help you much programming a multi-core GPU, that's much more high level than these books go, the first books just go over 'basic' algorithms but a lot of it (most of it) is still very relevant in my opinion IF you're working close to the core, the code that ends up executing on a single processor on that GPU.

Good books, but

[jgotts]

I own all of them, but to be honest I haven't cracked any book at work since at least 2009. I work on a web services-based POS, a fairly advanced but typical piece of technology for the working world. My comment shouldn't apply to programming in a research environment, but most people aren't doing that type of programming. I'm talking about your average piece of software.

Most programming "in the real world" is maintaining other people's code and making incremental improvements.

The first art of computer programming is figuring out other people's mistakes and correcting them. The second art of computer programming is communicating the work you've done to the next person. The third art is writing code that is so straightforward that an inexperienced programmer can understand what you did so that he can fix your bugs and make his own incremental improvements.

The information in textbooks and books such as TAOCP has been available online for a decade. On the rare occasion that you as a programmer have to do a computer science-y thing, a Google search followed by research is your best course of action. Using books is just outmoded nowadays.

I've been programming since the 1980's so take this with a grain of salt. If you still use your dead tree library then more power to you. There is a different style of programming for every programmer. We have three full-time programmers here and we all have radically different styles but we barely write down anything and there isn't a single programming book in our current office. We barely use paper anymore. I personally write down no more than about 50 words a week.

There is a philosophy I subscribe to that if you can't explain something to your mother, then you don't understand what you're doing well enough. TAOCP is dense stuff. The information is there, and it is conveyed correctly. But that's the science, not the art, of computer programming. Sorry, Knuth.

I read a big chunk of it

[skeptikos]

Back in high school, I thought I was the most badass programmer on this planet. Could hand assemble code and hyper-optimize my programs counting clock cycles everywhere. I got into college. There was a book on algorithms in the small library the computer room had. I learned about asymptotic behavior. So I realized that my cleverly optimized O(n^2) sorting assembly program was going to eventually lose badly to a straightforward interpreted implementation of quicksort. Clearly I had to become good at this. I started reading all books I could find on the topic and very quickly I noticed that they all included a sentence meaning "If you want to understand the subtle underpinnings of this, see TAOCP." So I got a copy of volumes 1 & 3. It was expensive (I was not in USA and books were VERY expensive because of currency exchange issues). Mom & Dad chipped in and I still thank them for that. I borrowed volume 2 from a friend.

I decided to go though the book solving all exercises up to level 30. Saturday was my TAOCP day. I cannot say I read ALL of the text nor that I solved ALL problems of difficulty below 30, but I solved all that I tried and they were way more than a few. I even solve some in the 35 level, whenever I considered them interesting.

FF to the beginning my PhD studies at a good school in the USA: When taking the grad level Algorithms class, I was doing VERY well. The professor, a scary smart guy (now full professor at Stanford) asked me how may courses on algorithms and information theory I had taken. The answer was none. My undergrad degree was in Systems Engineering, from a crappy school in South America. I was never formally taught what a big-Oh was. That professor become my thesis advisor. He used to joke saying I was a walking encyclopedia of algorithms.

Will it work for everybody? Probably not. If you want to do theoretical CS, as I did, you will have to handle that math and some more anyways. CLR is more up to date and time efficient for learning. If you want to be a software engineer, chances are you are not going to be doing the heavy math, you will be using off the shelf algorithms.

Still TAOCP is a hell of a reference. Funny thing is, after finishing my PhD, I browsed through it. It looked simple, not very formal at all. I guess PhD does mean "permanently head damaged" :-)

No, but...

[uniquegeek]

... you can try Godel, Escher, Bach: An Eternal Golden Braid for some light reading

Separation of Concerns

[luis_a_espinal]

'supposed to be" ???

clearly you haven't been paying attention. All the attack vectors we currently have in code are because of the lack of coders, er, uh, sorry, I know you prefer the term 'developers' these days, don't do any-damn-thing about doing inputs testing or overflow, invalid input, etc.

So, don't climb on your high horse and lecture about how the 'best textbook' doesn't teach a damn thing about them, when that led to the code we now have to try to make secure.

So, also, if all that is, "... a given...", then why is none of it done reliably????

Ramble ramble, gurrr gurrr, hear me roar.

Oh, I've been paying attention. A significant chunk of my professional experience (22 years) has been involved in secure programming and in scanning and fixing vulnerabilities left by accident (or more often than not, by incompetent developers) in the commercial and defense sectors. I'm not exaggerating that my entire career has been devoted to fixing other people's fuck ups. So when I say something it is (most likely) because I have some experience in the matter. I am not an authority in the matter, nor I claim to know it all, but I sure make sure to check my premises when I speak.

People are sloppy, plain and simple. Cobbling security concerns in an algorithm book accomplishes nothing. There are tomes and tomes of material out there regarding secure development, security and what not. There are online encyclopedias devoted to secure programming in, say, Java or C/C++. A entire web site (https://www.cert.org/secure-coding/) is devoted to canonical attack vectors and remediations. There are industry standards out there, for anyone to read, regarding secure coding. Take the MISRA C guidelines or the Ada Ravenscar Profile for examples.

If people aren't bothered to even do a fucking google on the most common attack vectors when developing a web site or a device driver, what makes you think they will pay attention when technology-specific secure coding details are embedded in text designed for mathematical description of algorithms?

It is called separation of concerns. That exists for a reason, and any secure developer worth a damned shit knows why. Separation of concerns does not mean ignorance of concerns. The fact that you do not know the importance of this (and its implications) made me suspect the quality of the work you (if you do any work at all.)

You do not pick a book about Operating Systems or Hardware Architecture and expect a description of routing protocols, do you? If you pick a book on security, say, attack vectors or public key infrastructure, you do not expect to find a discussion on lower or upper bounds for a distributed hash algorithm, do you?

Same deal with security. You pick a book about security, and you study it. You pick a book about algorithms and you study it. You pick a book about operating systems, and you study it. You pick a book about networking, and you study it. And so on, and so on. And you do so throughout your studies and continue to do so throughout your career.

Expecting all shit to be cobbled together in the same book gets you one of those mediocre "Be a Rock Star Programdude in 24 Hours" kind of a deal.

Sorry to bust your bubble, but it is people like you that litter the software industry with crap that the rest of us have to clean. I guess I should be thankful for it, because fixing shit written by others (specially when it is critical) can be a financially rewarding experience.

The Art of Computer Programming

[Anonymous Coward]

These should be in every programmers library... they will never become dated... so I would not be afraid to call them classic.

These books are fantastic

[MooseMiester]

These are fantastic books, but they are not meant to be read cover to cover. They are reference volumes. Before the Internet this was what we had.

Had to laugh at the posters that say the books are too hard. In the early days of software development you wrote your own database...from scratch. Your program started with a loop that read the keyboard... You decided what key did what... You wrote your own screen handler... In the early days of the PC you modified the memory of the video card directly to draw things... So if you wanted a circle, you needed to know geometry!

I'm not saying those days were better by any means but algorithms do to things like maintain tree structures for your database indexes was a VERY hot topic of discussion around the "Dat water cooler.... And yes, I'm old :-)

Sherpa

[Anonymous Coward]

99.99% of the time it's just a mountain to climb. Mountain climbing is good exercise though.

Baah.

[Pig Hogger]

I got it 35 years ago. I found the pseudo-assembly code a turn-off, but I slogged through.

I picked it up again some 5 years ago, and the pseudo-assembly code totally turned me off