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

131–140 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#131

Post by fulafel »

userbinator wrote: post #27
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 appe…

A problem with that is that compiler technology hasn't really progressed to do big whole-program or data-layout optimizations from high level specs.

If we were closer to the model where a program would read its fixed inputs (for the run) and it would be specialized in place for the input using partial evaluation, with profile feedback for data accesses to help transforming the internal data representations to optimize storage requirement and cache access patterns, we would be much more motivated to specify many things abstractly enough to give machine representations of the code and data more freedoms.

Re: “Clean Code, Horrible Performance” Discussion

#132

Post by lucumo »

regularfry wrote: post #103
lucumo wrote: post #96

Earlier quoted context omitted.

It's really not. Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way". So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a ch…

That's not inconsistent with "good code will get rewritten until it's not good code." Good code that you need to change is code that can degrade as a result of that change. Nothing to do with "just changing code because they feel like it".

The good code will be changed after it has ceased to be good code too. And bad code can become good code in the process of changing it.

There is nothing that makes good code more or less likely to change than bad code.

Re: “Clean Code, Horrible Performance” Discussion

#133

Post by pkolaczk »

laserlight wrote: post #127
pkolaczk wrote: post #114

Earlier quoted context omitted.

Surprise: I don't use classes. Rust doesn't have them. :P

So, you’ve been arguing for using switch statements, instead of Clean Code’s suggestion of using object-oriented polymorphism, in a context where polymorphism doesn’t exist?

Not at all. Not having classes is not the same as not having polymorphism. Rust supports polymorphism just fine (and one could argue its support for polymorphism is actually much more advanced than that of Java's; but that's not enough reason to use it everywhere).

Re: “Clean Code, Horrible Performance” Discussion

#134

Post by Derbasti »

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.

Without concerted effort, any easy-to-change code naturally will be replaced by hard-to-change code.

Re: “Clean Code, Horrible Performance” Discussion

#135

Post by martinhath »

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.

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.

Re: “Clean Code, Horrible Performance” Discussion

#136

Post by martinhath »

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…

> Clean code / readable code / whatever you want to call it is often at odds with performance.

I disagree; or rather, I'd put it the other way around by saying that often you can get both clean code (by some metric) and reasonable performance. The patterns in e.g. the book by Robert Martin doesn't give you either, though.

> And for most enterprise projects it just doesn't matter.

It matters for the users. I use software that is slow for no good reason, and I'd like to live in a world where this is not the case.

Re: “Clean Code, Horrible Performance” Discussion

#137

Post by bitwize »

What Casey doesn't get is that for the vast, vast majority of code out there, reliability, maintainability, scalability (to hundreds of servers, or hundreds of software engineers working on the code base), testability, and observability trump raw performance.

CPU and RAM are cheap. By engineering your software to scale performance as close to linearly as possible with the addition of more CPU and RAM, you've changed the problem from one that requires the best engineers to solve into one that can be solved literally by throwing more money at it. At the largest software deployment scales this is totally doable, and it makes the most sense for the business.

Re: “Clean Code, Horrible Performance” Discussion

#138

Post by haspok »

userbinator wrote: post #27
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 appe…

The whole C64 scene are shaking their head in disbelief. The CPU couldn't care less about "easy readability" (whatever that even means) of your code. Ever heard of self-writing / self-modifying code? Probably an extreme example, and it can be used both ways - for performance reasons (unroll those loops!) or for abstraction (macros are your friend!).

Re: “Clean Code, Horrible Performance” Discussion

#139

Post by sgarland »

bitwize wrote: post #137

What Casey doesn't get is that for the vast, vast majority of code out there, reliability, maintainability, scalability (to hundreds of servers, or hundreds of software engineers working on the code base), testability, and observability trump raw performance. CPU and RAM are cheap. By engineering your software to scale performance as close to linearly as possible with the addition of more CPU and RAM, you've changed…

You've now pushed the problem to the infra team, thanks.

What happens when the spot instance that pops up is a much older generation, and your app suddenly runs far slower due to reduced memory bandwidth, CPU clock speed, etc.?

Re: “Clean Code, Horrible Performance” Discussion

#140

Post by tome »

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.

> Bad code drives good code out, because good code is easy to understand and change.

I call this the Peter Principle of Programming:

"Code increases in complication to the first level where it is too complicated to understand. It then hovers around this level of complexity as developers fear to touch it, pecking away here and there to add needed features."

http://h2.jaguarpaw.co.uk/posts/peter-principle/

Post reply on HN