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

61–70 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#61

Post by namaria »

robalni wrote: post #26
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 dange…

>good code is easy to change so it will easily get rewritten until it's not easy to change anymore

Sounds like the 'bad currency drives good currency out of circulation' problem. Bad code drives good code out, because good code is easy to understand and change.

Re: “Clean Code, Horrible Performance” Discussion

#62

Post by namaria »

jackblemming wrote: post #57
foo42 wrote: post #40

Earlier quoted context omitted.

that last paragraph is an excellent description of the problem!

Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.

Hm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...

Re: “Clean Code, Horrible Performance” Discussion

#63

Post by moomoo11 »

Or you know. Have a toolbelt. You keep tools on that belt and you use them as necessary.

Making a simple service? It’s in the descriptor. Just keep it simple.

Making something large that has a bunch of people working on it? Time to pull out the toolbelt.

Making something super mission critical? Use the right tools.

No approach is perfect. That’s why you use what makes most sense, mixing and matching, to put together what works best for the task at hand.

Anything else is noise and just ignore.

Re: “Clean Code, Horrible Performance” Discussion

#64

Post by microtherion »

thethirdone wrote: post #15
taneq wrote: post #4

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

The point is, without a reasonably clean starting point, you'll never get to apply those 20-25x optimizations in code bases beyond a certain size, because they've become a wasteland of mediocre micro-optimizations before you even get started.

So the sensible thing to do is to identify a component of manageable size, fence it off with suitable abstraction boundaries, and then apply optimizations WITHIN the confines of that component only.

Re: “Clean Code, Horrible Performance” Discussion

#65

Post by Manjuuu »

I don't recommend to juniors any of the books of people like Uncle Bob, Fowler, etc...

Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind:

What have they ever built?

Reading code from popular opensource projects and evaluating the different approaches they took is way more useful than reading those books, full of regurgitated wisdom from people with minimal street creed. And yes, maybe it's time to stop calling him "uncle", it's not your uncle, he has very little to teach. Start building, stop reading.

Re: “Clean Code, Horrible Performance” Discussion

#66

Post by rhdunn »

taeric wrote: post #21
thethirdone wrote: post #18

Earlier quoted context omitted.

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.

That quote isn't saying not to optimize. It's saying not to optimize at the start.

When you initially write your code, you won't know where the bottlenecks are. So first choose and write a sensible implementation using appropriate algorithms and data structures to complete the task.

Then, when you have something working, measure its performance against real world data, not against synthetic benchmarks. You can use synthetic data that models the real world (e.g. a large number of user records in the system) to amplify the performance issues, but collecting the data from real world data will be better.

With that performance profile, you can see exactly where the performance issues are. Those will then allow you to write more complex, or harder to read code, that improves the performance of that part of the codebase. This will then allow you to write code that actually improves performance, and not things you think will improve performance, such as:

1. The optimized inverse square root function in Doom (https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...)

2. Improving the git performance of the sha1 algorithm. (There was a discussion about rewriting the old code a while ago in assembly in the mailing lists that I can't find due to Google not understanding my search queries. In those discussions, IIRC Linus ended up creating a C implementation that compilers were able to compile into an efficient assembly version.)

Re: “Clean Code, Horrible Performance” Discussion

#67

Post by blondin »

Spiwux wrote: post #55

I really do not understand why this is a discussion, why a video had to be made about it and why we now need an interview about this. Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of…

it did add something of value.

uncle bob realized his "clean code" may have done a disservice with regards to performance. but i am not holding my breath on seeing a change come about soon.

it is possible to optimize for both performance and developer productivity. but everybody is leaving that out in the discussion.

Re: “Clean Code, Horrible Performance” Discussion

#68

Post by augustk »

readlikeasloth wrote: post #32
wirrbel wrote: post #31

Earlier quoted context omitted.

Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…

This begs the question: what do you recommend instead?

"Code Complete" by Steve McConnell and "A Philosopy of Software Design" by John Ousterhout.

Re: “Clean Code, Horrible Performance” Discussion

#69

Post by iovrthoughtthis »

namaria wrote: post #61
robalni wrote: post #26

Earlier quoted context omitted.

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

>good code is easy to change so it will easily get rewritten until it's not easy to change anymore Sounds like the 'bad currency drives good currency out of circulation' problem. Bad code drives good code out, because good code is easy to understand and change.

exactly
Post reply on HN