3 ms·

Focusing on readability of the code and putting "machine execution" second, means putting the user experience second Nothing kills a users exper

by zaphar 8y ago

Focusing on readability of the code and putting "machine execution" second, means putting the user experience second Nothing kills a users experience like buggy code. Nothing contributes more to buggy code than unreadable or unclear code. This is why another proverb often quoted is "First make it correct, then make it fast". Fast but buggy code will lose to slower but correct code everytime.

titzer 8y ago
> Fast but buggy code will lose to slower but correct code everytime. I wish this were true, but unfortunately C++ proves this is not the case. Fast and buggy seems to be the holy grail there.
- rusticpenn 8y ago
  because being first to market is much more important than having the perfect tool.
atq2119 8y ago
> Fast but buggy code will lose to slower but correct code everytime. This is unfortunately not always true. It depends on what the consequences for incorrectness are. Outside of enterprise and the web, fast code can be an important selling point, and it may end up being prioritized over correctness, as long as the result is "correct enough". I wish it weren't so.
- zaphar 8y ago
  Something being correct enough is another way of saying "Most if not all of our users will never experience this." That's essentially saying that the code is not buggy. Now if your code is such that most of your users frequently experience incorrect behavior then I think you'll discover that you'll lose to a competitor.
jodrellblank 8y ago
Nothing kills a users experience like buggy code. [..]Fast but buggy code will lose to slower but correct code everytime. Remind me how Chrome took over the browser market with "Chrome Fast" as its slogan? How did nginx grow so popular against Apache? Was it promoted as "less buggy" or "faster"? How MySQL became so prominent, was that people choosing "slower but more correct"? How MongoDB became so popular - "slower but more correct" winning out? Cite some instances of when "slower but more correct" has ever won out, assuming the faster system does work? Nothing contributes more to buggy code than unreadable or unclear code. That's quite likely false. Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. Nothing contributes more to buggy code than simply more code. To quote Arthur Whitney: "The only program which stands a chance of being correct is a short one."
- zaphar 8y ago
  Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. Everytime this topic comes up someone brings up this point. The counter to it is always the same. In the lifetime of those ten characters someone who is not the original author will have to modify it. Because it is not clear what exactly the code is doing they will probably introduce a subtle bug. Iterate on that a few times and eventually you will have code that literally no one can safely touch and the only way to fix it will be to rewrite it. If the person doing the rewrite is smart and looks at why the rewrite was necessary they will change those "ten characters" to however many it takes to make it understandable for the future maintainer. It should be exactly as short as necessary to be clearly correct and no shorter. Then you can work at making it faster with appropriate comments about why this particular speed hack is necessary and what you need to know before you modify it.
  - jodrellblank 8y ago
    You want a large amount of code, because you're afraid of maybe having to rewrite a small amount of code? How does that make sense, and why won't the large amount go through the same iterative adjustment and subtle bugs until it needs rewriting? Because it is not clear what exactly the code is doing A ten character English which name vaguely describes what a function hidden in another file might have been doing (assuming you understand the word in the same way the author did when they chose it) at the time it was written - but it might not be doing the same thing now since it was edited so many times, is not exact. By contrast, ten dense characters right there under your nose is exact - as much as a programming language can be. There's nothing hidden, no surprises, no unseen side effects, no uncertainty about whether it handles edge cases. Code is as exact as it gets - it does what the language does. Abstractions are less exact - they do some version of what the previous chain of developers intended the words to imply that they do, in the best case. In worse cases they also do unrelated and surprising things. And you dodged every question about when slow but correct code won out over faster, more buggy code.

by zaphar 8y ago

titzer 8y ago

> Fast but buggy code will lose to slower but correct code everytime. I wish this were true, but unfortunately C++ proves this is not the case. Fast and buggy seems to be the holy grail there.

rusticpenn 8y ago
because being first to market is much more important than having the perfect tool.

atq2119 8y ago

> Fast but buggy code will lose to slower but correct code everytime. This is unfortunately not always true. It depends on what the consequences for incorrectness are. Outside of enterprise and the web, fast code can be an important selling point, and it may end up being prioritized over correctness, as long as the result is "correct enough". I wish it weren't so.

zaphar 8y ago
Something being correct enough is another way of saying "Most if not all of our users will never experience this." That's essentially saying that the code is not buggy. Now if your code is such that most of your users frequently experience incorrect behavior then I think you'll discover that you'll lose to a competitor.

jodrellblank 8y ago

Nothing kills a users experience like buggy code. [..]Fast but buggy code will lose to slower but correct code everytime. Remind me how Chrome took over the browser market with "Chrome Fast" as its slogan? How did nginx grow so popular against Apache? Was it promoted as "less buggy" or "faster"? How MySQL became so prominent, was that people choosing "slower but more correct"? How MongoDB became so popular - "slower but more correct" winning out? Cite some instances of when "slower but more correct" has ever won out, assuming the faster system does work? Nothing contributes more to buggy code than unreadable or unclear code. That's quite likely false. Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. Nothing contributes more to buggy code than simply more code. To quote Arthur Whitney: "The only program which stands a chance of being correct is a short one."

zaphar 8y ago
Ten characters of unreadable code written by an expert will have fewer bugs than 100,000 lines of "readable, clear" C++ code written by a novice. Everytime this topic comes up someone brings up this point. The counter to it is always the same. In the lifetime of those ten characters someone who is not the original author will have to modify it. Because it is not clear what exactly the code is doing they will probably introduce a subtle bug. Iterate on that a few times and eventually you will have code that literally no one can safely touch and the only way to fix it will be to rewrite it. If the person doing the rewrite is smart and looks at why the rewrite was necessary they will change those "ten characters" to however many it takes to make it understandable for the future maintainer. It should be exactly as short as necessary to be clearly correct and no shorter. Then you can work at making it faster with appropriate comments about why this particular speed hack is necessary and what you need to know before you modify it.
- jodrellblank 8y ago
  You want a large amount of code, because you're afraid of maybe having to rewrite a small amount of code? How does that make sense, and why won't the large amount go through the same iterative adjustment and subtle bugs until it needs rewriting? Because it is not clear what exactly the code is doing A ten character English which name vaguely describes what a function hidden in another file might have been doing (assuming you understand the word in the same way the author did when they chose it) at the time it was written - but it might not be doing the same thing now since it was edited so many times, is not exact. By contrast, ten dense characters right there under your nose is exact - as much as a programming language can be. There's nothing hidden, no surprises, no unseen side effects, no uncertainty about whether it handles edge cases. Code is as exact as it gets - it does what the language does. Abstractions are less exact - they do some version of what the previous chain of developers intended the words to imply that they do, in the best case. In worse cases they also do unrelated and surprising things. And you dodged every question about when slow but correct code won out over faster, more buggy code.