2 ms·

Then you should spend some more time on HN or reddit and you will definitely hear this. It's bound to pop up sooner or later in topics where programming languag

by blub 11y ago

Then you should spend some more time on HN or reddit and you will definitely hear this. It's bound to pop up sooner or later in topics where programming languages are discussed. Here's a comment where someone says that performance doesn't matter at all if you only have a certain number of users and then they backtrack and qualify their statements: https://news.ycombinator.com/item?id=11245700 https://news.ycombinator.com/item?id=11245700 I have the opposite impression - that many devs are lazy and don't think about optimisation at all. They write slow code by default and hide behind a misquoted Knuth. Your definition is off by the way, writing fast code and doing optimisation doesn't necessarily mean that the code will be less understandable or become brittle. e.g: using range va xrange in Python 2.x when iterating over large ranges - that's a difference of literally one letter. There are of course other examples.

crdoconnor 11y ago
>using range va xrange in Python 2.x when iterating over large ranges - that's a difference of literally one letter. Which literally makes no noticeable difference 97% of the time. I wouldn't necessarily complain if you did that to my code as part of a broader refactor but if the range is small you're not doing anybody any favors.
jlebar 11y ago
Your definition is off by the way, writing fast code and doing optimisation doesn't necessarily mean that the code will be less understandable or become brittle. OP said Optimization often involves making code less clear, more brittle Seems you're arguing against a straw man here.
- blub 11y ago
  Not quite. * OP is arguing that optimisation is usually problematic from multiple perspectives. Here's the full quote: Optimization often involves making code less clear, more brittle, or with a more pasta-like organization. Frequently optimization requires writing code that if looked at out of context, doesn't make sense or might even look wrong. * I am arguing that these assumptions cannot be made so easily. Yes, they qualified the statements with "often" and "frequently", but the tone is clearly negative. It shouldn't be, and we shouldn't shun writing fast code out of the belief that it's at odds with readability or robustness.

by blub 11y ago

crdoconnor 11y ago

>using range va xrange in Python 2.x when iterating over large ranges - that's a difference of literally one letter. Which literally makes no noticeable difference 97% of the time. I wouldn't necessarily complain if you did that to my code as part of a broader refactor but if the range is small you're not doing anybody any favors.

jlebar 11y ago

Your definition is off by the way, writing fast code and doing optimisation doesn't necessarily mean that the code will be less understandable or become brittle. OP said Optimization often involves making code less clear, more brittle Seems you're arguing against a straw man here.

blub 11y ago
Not quite. * OP is arguing that optimisation is usually problematic from multiple perspectives. Here's the full quote: Optimization often involves making code less clear, more brittle, or with a more pasta-like organization. Frequently optimization requires writing code that if looked at out of context, doesn't make sense or might even look wrong. * I am arguing that these assumptions cannot be made so easily. Yes, they qualified the statements with "often" and "frequently", but the tone is clearly negative. It shouldn't be, and we shouldn't shun writing fast code out of the belief that it's at odds with readability or robustness.