Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

“Clean Code, Horrible Performance” Discussion

github.com

Post reply on HN
Print view View original

21–30 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#21

Post by taeric »

thethirdone wrote: post #18
nayuki wrote: post #9

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, 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…

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.

Re: “Clean Code, Horrible Performance” Discussion

#24

Post by userbinator »

All the concentration on "developer productivity" has lead to a massive loss of user productivity and wasted energy. Ironically, a lot of developers are also users, so they suffer just the same.

The worst part is, AFAIK it's not even clear that the recommendations in Clean Code are better for developer productivity, insofar as they create excessive complexity.

Another thing to note is that I've observed a significant fraction of users (and developers!) seem to have a very poor perception of time. You can replace an app they were using with one that is otherwise exactly the same but introduces a whole second of delay when interacting with the UI, and they wouldn't notice unless you gave them the two versions to compare side-by-side. Of course another significant fraction does notice, which is why you often see both "this new version is horribly slow" and "works fine for me, it doesn't feel any slower" opinions.

Re: “Clean Code, Horrible Performance” Discussion

#26

Post by robalni »

pkolaczk wrote: post #8

It 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…

I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?"

Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated.

That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.

Re: “Clean Code, Horrible Performance” Discussion

#27

Post by userbinator »

pkolaczk wrote: post #8

It 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…

So many times I've seen a more readable, simpler code turned out to be more efficient as well.

In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around.

The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appear, are also easier to find and fix.

Re: “Clean Code, Horrible Performance” Discussion

#28

Post by slavik81 »

wokwokwok wrote: post #5

Some gems from the discussion… > Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.” > You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is…

> there is an almost fundamental disconnect between “easy to understand” and “fast and efficient”

In my experience, poor performance is often because the code is needlessly complex and does unnecessary work. In that case, there's no trade-off. You can both improve performance and readability by simplifying.

There may be trade-offs required to optimize for the absolute maximum performance, but you can get most of the way there without sacrificing anything. The vast majority of programs are nowhere near the pareto frontier between performance and readability.

Re: “Clean Code, Horrible Performance” Discussion

#29

Post by xjay »

brtkdotse wrote: post #17
nayuki wrote: post #9

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, 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.

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

Re: “Clean Code, Horrible Performance” Discussion

#30

Post by teo_zero »

> It is economically better for most organizations to conserve programmer cycles than computer cycles

This is only true if "organizations" here means those which write the program. If you include those who actually use the program, I don't see how this sentence could be proved.

Post reply on HN