nesdev.com

because it looks as sharp as the Sega version, just with a smaller screen.

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

It would've made more sense if he said "unnecessary optimization" instead of "premature optimization". "Premature" sounds like you shouldn't make any optimizations early on.

I absolutely hate those one lined so-called "rules". They make absolutely no sense, as if you could summary good and bad programming practice in 5 (or so) lines.

It depends so much on the context, if you are in education, or industry, if you are writing for your hobby or just because you're paid to do so, if you have deadlines or not, if you want to make elegant code, and of course even if in theory the programming language is not related to programming in itself, in practice it is, so yes it will depend on the programming language.

It is absolutely wrong to say you can't know where a program is going to spend it's time. In fact if you have half a brain you can guess it very easily. The only exception is if you are doing system calls and have no idea what the library will do behind it. Which may be pretty much always the case of people programming in very high level language, where they have no idea what they're actually doing on the machine.

And, the sentence, "premature optimisation is the root of all evil" is simply stupid and was probably a dumb joke, but people took it seriously.

I think it would be trivial to find one evil which is not due to premature optimisation. For instance, nazism was not a premature optimisation. Enough said.

Now let's pretend "premature optimisation is the root of all bad-programming practice (aka "evil") ". Again this is wrong. Some of the random programming practices that comes in mind :

- Bad indentation
- Variable names that makes no sense or aren't related to the variable's purpose
- Function names that makes no sense or [...]
- Not comment what a function expect as input and output
- Writing too much stuff on one line like : while (--i != function_call(arg1++, arg2))
- Copy-paste a function and make it only slightly different, instead of using an extra argument

None of those bad practices are premature optimisation, so again this sentence is plain wrong.

Now let's dumb it down to "premature programming optimisation is the root of some bad-programming practice (aka "evil")"

Then finally this is true of course (at last). If you want to make a super optimal program before writing it, there is higher probability you'll write spaghetti code and fail or simply loose interest in continuing it, because it's too much effort (if you're a hobbyist).

However, completely ignore any kind of "optimisation" when programming is not a very good practice either. You should really think about the proper data structures, so that you'll gain time, and not having to say "oh if I use structure Y instead of structure X, my program could be 10x faster" and having to rewrite everything.

So my advice is to optimize data structure first, then write clear, commented code (having it "optimized" is ok as long as it doesn't discard the comprehension), and finally, make a few optimizations that could alter the comprehension of the code if it is needed.

Also, optimising non-bottlenecks is not a crime. It's just a waste of your time in the worst case, but it won't hurt the performance in any way. Don't get me wrong - optimising bottlenecks is better, but that doesn't make optimise the rest wrong. There is plenty of situations where measuring the bottleneck directly is simply impossible or terribly difficult, so you'll have to resort to cheap heuristics.

Conclusion : I think paradoxally those dumb one-liners and people citing them as if it was the bible is the reason there's so many bad programmers around. In reality most of the approach depends on the context (embedded or not, hobby or work) and programming language. Just don't trust one-liners without thinking.

I'd say : "Dumb one-liners are the root of all evil".

The idea is that it's hard to predict in advance what parts of your code will be the bottleneck

I absolutely hate those one lined so-called "rules". They make absolutely no sense, as if you could summary good and bad programming practice in 5 (or so) lines.