4 ms·

At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I watched Casey's video in f

by nayuki 4y ago

At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem. As an addendum to Casey's video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD/vectorization. https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.

brtkdotse 4y ago
> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I fully agree that human comprehension should be a prime objective for code. Alas, following the tenets of “Clean Code” produces anything but that.
- xjay 4y ago
  I know that the original "MVC guy" and "Bob's nemesis" :^) have been looking into making human comprehension the main goal of a new programming language, "trygve", named after Trygve Reenskaug (MVC). https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction
thethirdone 4y ago
I don't think Casey would object to "optimizing for human comprehension". If you are willing to give up an order of magnitude of performance, you can probably just do it without much care. I agree that "optimizing for human comprehension" is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don't think that guidelines like "clean code" actually are particularly effective at making understandable code. My personal guideline is to prefer code which is "simple" for both humans and computers. > So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it. I hold the controversial opinion that Knuth's advice is not relevant to most modern programmers. Most modern programmers have never done the "optimization" that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won't be significant hotspots. Everything will be lukewarm.
- taeric 4y ago
  Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.
  - inimino 4y ago
    Since this gets repeated so often, it is probably worth reproducing a little more of Knuth's quote. "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code, but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." The context for this statement, is of course his article [1] saying that goto statements should not be regarded as bad for religious reasons, but should be used appropriately. How common is the pragmatic approach to goto today, vs the "religious" response to goto? So this is the context in which it's appropriate to quote Knuth on this: if you are thinking about efficiency all the time, making intuitive guesses about where your programs will be slow, using measurement tools after the fact, and in danger of spending your optimization efforts on 100% of the code instead of 3%, and if you have a rational rather than emotional response to seeing goto statements in your codebase, then Knuth's quote is for you. What he was really arguing for is a practical, rational approach rather than religious, emotional responses. Which was also Dijkstra's point about goto. The whole article is well worth a read if you haven't already seen it. [1]: https://dl.acm.org/doi/pdf/10.1145/356635.356640 https://dl.acm.org/doi/pdf/10.1145/356635.356640
    - dceddia 4y ago
      Much like Chuck Norris references in movies from 2004, I get the sense that this advice is a product of its time. One of those “it makes more sense if you were there” things. (It even starts off acknowledging that it’s an article about current trends!) Not to say it doesn’t generally still hold true, but this part stuck out to me: > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs I don’t think this is widely true today (outside e.g. game development anyway). If it were, we’d probably have lots of fast software that’s very hard to read! But computers were a lot slower then, compilers weren’t as advanced, and it would make a lot of sense if performance was top of mind for most programmers at the time.
wetmore 4y ago
From what I understand the main benefit of struct-of-array is that it is more cache and alignment friendly.
dsego 4y ago
> invert the normal array-of-structs to a struct of arrays We need our languages and compilers to give us the necessary tools to abstract away complexity without losing performance, which our current OOP languages don't really do. Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA. https://pixeldroid.com/jailang/overview/Features/SOA/#/overview/ https://pixeldroid.com/jailang/overview/Features/SOA/#/overv...
- Measter 4y ago
  > Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA. I believe Zig has a stdlib function that allows you to do this, and I'm pretty sure there's also a Rust crate that provides a proc macro for it.
martinhath 4y ago
> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. Nobody is arguing against comprehensible code. Caseys video is not about clean code in general, but "Clean Code" as presented e.g. in the book by Robert Martin, which contains a bunch of code I would not classify as "clean" by any metric. > But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic He doesn't, though. The "Clean Code, Horrible Performance" video is an excerpt from his course called "Performance-Aware Programming", where he explicitly says many times that the course isn't at all about "optimization", but merely being "performance aware". This isn't highlighted in the video though, so getting the full context is difficult.
ajmurmann 4y ago
I think Clean Code is more about the ability to easily change the code as requirements change. Readability is one factor, but many of the rules really are only about ease of change. Open/closed and dependency inversion are prime examples of guidelines that are all about ease of change.

by nayuki 4y ago

brtkdotse 4y ago

> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. I fully agree that human comprehension should be a prime objective for code. Alas, following the tenets of “Clean Code” produces anything but that.

xjay 4y ago
I know that the original "MVC guy" and "Bob's nemesis" :^) have been looking into making human comprehension the main goal of a new programming language, "trygve", named after Trygve Reenskaug (MVC). https://en.wikipedia.org/wiki/Data,_context_and_interaction https://en.wikipedia.org/wiki/Data,_context_and_interaction

thethirdone 4y ago

I don't think Casey would object to "optimizing for human comprehension". If you are willing to give up an order of magnitude of performance, you can probably just do it without much care. I agree that "optimizing for human comprehension" is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don't think that guidelines like "clean code" actually are particularly effective at making understandable code. My personal guideline is to prefer code which is "simple" for both humans and computers. > So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it. I hold the controversial opinion that Knuth's advice is not relevant to most modern programmers. Most modern programmers have never done the "optimization" that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won't be significant hotspots. Everything will be lukewarm.

taeric 4y ago
Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.
- inimino 4y ago
  Since this gets repeated so often, it is probably worth reproducing a little more of Knuth's quote. "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code, but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail." The context for this statement, is of course his article [1] saying that goto statements should not be regarded as bad for religious reasons, but should be used appropriately. How common is the pragmatic approach to goto today, vs the "religious" response to goto? So this is the context in which it's appropriate to quote Knuth on this: if you are thinking about efficiency all the time, making intuitive guesses about where your programs will be slow, using measurement tools after the fact, and in danger of spending your optimization efforts on 100% of the code instead of 3%, and if you have a rational rather than emotional response to seeing goto statements in your codebase, then Knuth's quote is for you. What he was really arguing for is a practical, rational approach rather than religious, emotional responses. Which was also Dijkstra's point about goto. The whole article is well worth a read if you haven't already seen it. [1]: https://dl.acm.org/doi/pdf/10.1145/356635.356640 https://dl.acm.org/doi/pdf/10.1145/356635.356640
  - dceddia 4y ago
    Much like Chuck Norris references in movies from 2004, I get the sense that this advice is a product of its time. One of those “it makes more sense if you were there” things. (It even starts off acknowledging that it’s an article about current trends!) Not to say it doesn’t generally still hold true, but this part stuck out to me: > Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs I don’t think this is widely true today (outside e.g. game development anyway). If it were, we’d probably have lots of fast software that’s very hard to read! But computers were a lot slower then, compilers weren’t as advanced, and it would make a lot of sense if performance was top of mind for most programmers at the time.

wetmore 4y ago

From what I understand the main benefit of struct-of-array is that it is more cache and alignment friendly.

dsego 4y ago

> invert the normal array-of-structs to a struct of arrays We need our languages and compilers to give us the necessary tools to abstract away complexity without losing performance, which our current OOP languages don't really do. Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA. https://pixeldroid.com/jailang/overview/Features/SOA/#/overview/ https://pixeldroid.com/jailang/overview/Features/SOA/#/overv...

Measter 4y ago
> Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA. I believe Zig has a stdlib function that allows you to do this, and I'm pretty sure there's also a Rust crate that provides a proc macro for it.

martinhath 4y ago

> At some point in my programmer career I figured out that optimizing for human comprehension, a.k.a. "clean code", is a valid goal. Nobody is arguing against comprehensible code. Caseys video is not about clean code in general, but "Clean Code" as presented e.g. in the book by Robert Martin, which contains a bunch of code I would not classify as "clean" by any metric. > But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic He doesn't, though. The "Clean Code, Horrible Performance" video is an excerpt from his course called "Performance-Aware Programming", where he explicitly says many times that the course isn't at all about "optimization", but merely being "performance aware". This isn't highlighted in the video though, so getting the full context is difficult.

ajmurmann 4y ago

I think Clean Code is more about the ability to easily change the code as requirements change. Readability is one factor, but many of the rules really are only about ease of change. Open/closed and dependency inversion are prime examples of guidelines that are all about ease of change.