6 ms·

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there

Programs must be written for people to read, and only incidentally for machines to execute. –Hal Abelson and Gerald Sussman Often quoted, and I wonder if there's much evidence supporting it? Let's replace "machines execute it" with "people use it without reading the source code", and we can say that code is run many many more times than it is read. Focusing on readability of the code and putting "machine execution" second, means putting the user experience second, after the developer experience. Imagine a race car engine which is designed first to be simple for an unfamiliar contract mechanic to repair, and secondly to power a race car, with the justification that the engine "will be repaired more often than it will be built". I have my suspicions that software which is fast, responsive, and a pleasure to use is designed by people who put the machine first; even if that means using difficult languages and low levels of abstraction and requires high levels of skill. The most important skill for a programmer is the ability to effectively communicate ideas Iverson Notation was designed as an improved way for people to communicate ideas, years before it got turned into the programming language APL. Look where that got it. Go programmers realise that code is written to be read and so place the act of reading code above the act of writing it. Go goes so far as to enforce, via tooling and custom, that all code be formatted in a specific style. Books are created to be read, not written. That doesn't happen by enforcing that all books have the same style and formatting. If software cannot be maintained, then it will be rewritten; and that could be the last time your company will invest in Go. Pushing a cult is the last word in the slides?

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.
Nasrudith 8y ago
To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern. More charitably, a better argument is that it is easier to adapt a compiler to reoptimize it than to tweak the entire code base - let alone the costs for the gains.
- dullgiulio 8y ago
  We have been waiting for the "sufficiently smart compiler" for around 4 decades now. If it's so easy to write one, where are they?
  - Nasrudith 8y ago
    It is on a spectrum but it is already here to some extent. Look at previous performance practices which have become deprecated like manually unrolling fixed for loops. Those are the sorts of things which have been fixed up and assembly coding is pretty rare still.
- throwaway55554 8y ago
  >... but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. No, it doesn't suggest this at all. It means use the merge sort but implement it in a clean, understandable way.
  - jodrellblank 8y ago
    It means use the merge sort but implement it in a clean, understandable way. https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort - which ones of these do you consider objectively "clean and understandable"? Why should any of them (Prolog, Mercury, J, Common-Lisp, etc) be considered "not understandable" instead of "not familiar to the reader"?

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.

Nasrudith 8y ago

To be frank I have always found such dogmatism deeply questionable. I can understand caveats like "for long term maintainability" but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. Insisting upon not referring to reality is not a good pattern. More charitably, a better argument is that it is easier to adapt a compiler to reoptimize it than to tweak the entire code base - let alone the costs for the gains.

dullgiulio 8y ago
We have been waiting for the "sufficiently smart compiler" for around 4 decades now. If it's so easy to write one, where are they?
- Nasrudith 8y ago
  It is on a spectrum but it is already here to some extent. Look at previous performance practices which have become deprecated like manually unrolling fixed for loops. Those are the sorts of things which have been fixed up and assembly coding is pretty rare still.
throwaway55554 8y ago
>... but taken literally it suggests assinine ideas like using bubble sort instead of merge sort for a large set not because of any memory footprint constraints but because it is easier to read. No, it doesn't suggest this at all. It means use the merge sort but implement it in a clean, understandable way.
- jodrellblank 8y ago
  It means use the merge sort but implement it in a clean, understandable way. https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort https://rosettacode.org/wiki/Sorting_algorithms/Merge_sort - which ones of these do you consider objectively "clean and understandable"? Why should any of them (Prolog, Mercury, J, Common-Lisp, etc) be considered "not understandable" instead of "not familiar to the reader"?