Recent and related:
“Clean” code, horrible performance - https://news.ycombinator.com/item?id=34966137 - Feb 2023 (906 comments)
“Clean Code, Horrible Performance” Discussion
11–20 of 220 posts
Re: “Clean Code, Horrible Performance” Discussion
#12The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so mu…
Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code.
(I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)
Re: “Clean Code, Horrible Performance” Discussion
#13> preferring inheritance hierarchies to if/switch statements,
And then he goes on touting readability right after that. Bold.
Re: “Clean Code, Horrible Performance” Discussion
#14It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…
Clean Code led to the development of the VIPER framework, which is a crime it must answer for.
Re: “Clean Code, Horrible Performance” Discussion
#15Clean code makes it easier to find high level optimisations which can improve the order of performance, not just shave off a few percent.
From: https://www.computerenhance.com/p/clean-code-horrible-perfor...
> The speed differences range from 20-25x — and of course, none of the AVX-optimized code uses anything remotely like “clean” code principles.
If clean code limits your default performance to 20 times worse, those high level optimizations might not even be worth it.
Re: “Clean Code, Horrible Performance” Discussion
#16This exchange was more enjoyable than I anticipated it to be.
> I created this with vi and used 1,$s/ /:/g
> Because, I really am an old C hacker at heart.
%s/ /:/g would have been shorter.
Re: “Clean Code, Horrible Performance” Discussion
#17At 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, anoth…
> 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.
Re: “Clean Code, Horrible Performance” Discussion
#18At 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, anoth…
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.
Re: “Clean Code, Horrible Performance” Discussion
#19Here's another controversial opinion:
It's the genius programmers who write the shittiest code. In my experience clean code tends to be a waste of time for geniuses because shitty code isn't really a problem for smarter people.
The further away you are from genius the greater the tendency for you to write cleaner code because you need it in order to deal with the complexity.
What's common among HN readers is that they think they're smart. So you may be reading this and thinking "Wait a minute, this isn't true! I'm smart and I like clean code!". Well, I hate to break it to you. The truth hurts because most likely one of those two attributes probably doesn't actually describe you.
Also as a side mention, I'm a clean code Nazi. My code is really clean.
Re: “Clean Code, Horrible Performance” Discussion
#20The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so mu…
Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code. (I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)
No need to make assumptions given that they dug into that issue and the problem was algorithmic. As Bob points out that's orthogonal to clean code ideas. If you chose the wrong datastructure or algorithm and have quadratic complexity all the micro-optimizations in the world aren't going to help you.
The only strawman honestly is to pick someone at github writing shoddy code and then using that to argue against system architecture? It's pretty obvious that a text editor lagging on a paragraph of text isn't the consequnce of having wrapped something in a function. If you've written code slower than a human you don't have clean code, you just have bad code.