Based on cursory review of the information surrounding the quote, I'm in a position of "initial reluctance to agree."
I'm thinking that part of that 97% he talks about should be addressed if it can be done without significant overhead to getting the code written and tested.
Need to take a deep dive to see if my initial position holds fast.
Then again, who am I to disagree with the distinguished Dr. Knuth! :-P
I don't disagree with Knuth at all. I do disagree with what many people have erroneously come to believe that he means. If you read the preceding paragraphs from the right column of the preceding page through the text up to the "evil" statement, you'll see why I get so ticked when someone uses the "evil" statement to justify poor design including but not limited to the use of RBAR for small numbers of rows or one-off jobs and using the wrong data-types in the initial design of tables.
Yes, Knuth states that it's a waste of time to spend time to "optimize" one-off jobs and I mostly agree with that. But if you already know a way to have the code run faster and it takes no extra dev time to do so, why would anyone intentionally write it using a slower, "less optimal" method?
That's a subject that I don't believe Knuth spent enough time on... learning and practicing the optimal methods so that they become second nature so that they don't actually take any extra time to incorporate in areas that are known to be troublesome insofar as performance goes. To wit, that's not "premature optimization" in my book. That's knowing the trade and understanding known design problems.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair
How to post code problemsHow to post performance problemsForum FAQs