3 ms·

I didn't know this, thanks for pointing it out. I think this has been a costly misinterpretation of "premature optimisation". This phrase has been taken as jus

by jraph 3y ago

I didn't know this, thanks for pointing it out. I think this has been a costly misinterpretation of "premature optimisation". This phrase has been taken as justification for writing inefficient code, understanding it as "performance doesn't matter [for what we do]". It almost always matters, and I believe it is possible to write both efficiently and in a readable way. Unfortunately, inefficient code is well established, in habits and even in (sometimes mandatory) coding styles. This inefficiency also often translates to hard to follow code because of too much abstraction. Maybe we could counter this misinterpretation of "premature optimisation" with "premature abstraction".

ReleaseCandidat 3y ago
> This phrase has been taken as justification for writing inefficient code, understanding it as "performance doesn't matter [for what we do]". There is no contradiction. Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised. How do you measure the "optimisation" without "inefficient code" as baseline to begin with?
- edflsafoiewq 3y ago
  In that case, how do you know you're measuring the "optimization" and not "how awful the original code was"?
- jraph 3y ago
  > Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised. What about inefficient code only if you _know_ that it does not matter? I'm not talking about optimizing. I'm talking about avoiding inefficiencies in the first place. This is what I'm talking about: we are in "inefficient by default" mode. That leads to requiring powerful hardware to display the most lambda websites.
- vlovich123 3y ago
  Depends what you mean by inefficient. The other thing Knuth meant is that you should focus your efficiency energy first on overall design efficiency. Algorithmic and other efficiencies are irrelevant if your design is bad and a bad design cannot be fixed by looking at the profiler and fixing hotspots

by jraph 3y ago

ReleaseCandidat 3y ago

> This phrase has been taken as justification for writing inefficient code, understanding it as "performance doesn't matter [for what we do]". There is no contradiction. Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised. How do you measure the "optimisation" without "inefficient code" as baseline to begin with?

edflsafoiewq 3y ago
In that case, how do you know you're measuring the "optimization" and not "how awful the original code was"?
jraph 3y ago
> Writing inefficient code is perfectly fine until you _know_ (this means you have measurements that show that) it is _too_ inefficient and has to be optimised. What about inefficient code only if you _know_ that it does not matter? I'm not talking about optimizing. I'm talking about avoiding inefficiencies in the first place. This is what I'm talking about: we are in "inefficient by default" mode. That leads to requiring powerful hardware to display the most lambda websites.
vlovich123 3y ago
Depends what you mean by inefficient. The other thing Knuth meant is that you should focus your efficiency energy first on overall design efficiency. Algorithmic and other efficiencies are irrelevant if your design is bad and a bad design cannot be fixed by looking at the profiler and fixing hotspots