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

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

891–900 of 932 posts

Re: “Clean” code, horrible performance

#891

Post by berkes »

loup-vaillant wrote: post #871
berkes wrote: post #767

Earlier quoted context omitted.

> it failed. That is a large statement you make there. It begs for backing up.

Bob Martin should back his claims up. He asserted many things in his book, without evidence, and with examples so bad most of them actually hurt his case. "Clean Code" is just a bad book, best ignored. Great speaker, though. --- As for SOLID, there's one good thing: Barbara Liskov. Her principle have mathematical underpinnings in type theory, shapes Haskell's type classes and likely Rust traits too. The rest however…

Still sounds like your opinion vs his.

That's not "failing" that's at most "it doesn't work for me", but without explaining why it doesn't work for you, it really is little more than a wild claim.

I've had great success with "Clean code" practices. Though I implement it more according to Alistair Cockburns' "Hexagonal Architecture", it's overall very similar and strives for the same goals using the same methods. So in that sense, N=1 it hasn't failed. It has helped at least one person.

Re: “Clean” code, horrible performance

#892

Post by unconed »

Olreich wrote: post #107
unconed wrote: post #88

The example of using shape area seems like a poor choice. First off, the number of problems where having an analytical measure of shape area is important is pretty small by itself. Second, if you do need to calculate area of arbitrary shapes, then limiting yourself to formulas of the type `width * height * constant` is just not going to cut it. And this is where the entire optimization exercise eventually leads: to b…

To summarize: if you make the problem complex enough, then the specific performance methods used in the article don’t work. But hey, why not take your complex example? If you apply a polymorphic approach to Bézier curves and polygons, then you still get a 1.5x slowdown compared to a switch statement. If you have any commonality between your implementations of area for them, it’s harder to find, which could be worth 2…

Being able to handle arbitrarily polygons isn't insane complexity, it's actually the minimum viable complexity needed to handle any basic shape a user might want to use.

Limiting them to a handful of precomputed ones is the kind of limitation only a software developer can live with and love.

And once you can handle arbitrary polygons, writing and maintaining special case code has to be justified with evidence that your code is spending enough time on area calculations that it's worth optimizing and maintaining extra lines of code for.

Re: “Clean” code, horrible performance

#893

Post by Applejinx »

mabbo wrote: post #179

I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…

And then when you're not waiting for user input and you have a simple keystroke… how long is it taking you to show the result on the screen?

Re: “Clean” code, horrible performance

#894

Post by wellanyway »

thom wrote: post #74

There is no doubting Casey's chops when he talks about performance, but as someone who has spent many hours watching (and enjoying!) his videos, as he stares puzzled at compiler errors, scrolls up and down endlessly at code he no longer remembers writing, and then - when it finally does compile - immediately has to dig into the debugger to work out something else that's gone wrong, I suspect the real answer to progra…

Because enterprise Java programmers never stare puzzled at anything.

Re: “Clean” code, horrible performance

#895

Post by [deleted] »

jstimpfle wrote: post #213
st3fan wrote: post #149

Earlier quoted context omitted.

> The advocates of "clean code" that Casey mentions will go for extensibility no matter the use. Unfortunately this is just some catchy stereotyping that probably doesn't match reality.

The code examples with the abstract / virtual methods for the most straightforward concepts are a clown show. Not cleanliness but madness.

[deleted]

Re: “Clean” code, horrible performance

#896

Post by eropple »

incrudible wrote: post #691
eropple wrote: post #286

Earlier quoted context omitted.

In my experience: a profiler, usually. Just because I can throw down a lot of code quickly doesn't mean I don't have the tools to analyze code when I go "hmm, that seems slow".

That works for big hotspots, but not for the tiny papercuts that make every little thing 10x slower.

Sure. That's a tradeoff you consciously make to get the thing out the door. That's what technical debt is. You pay it down later. (Or you go bankrupt and it doesn't matter anymore.)

Re: “Clean” code, horrible performance

#897

Post by [deleted] »

mattgreenrocks wrote: post #230
athanagor2 wrote: post #18

Earlier quoted context omitted.

But is it true that "clean code" makes the adaptation to changing requirements easier? I saw a few testimonies saying otherwise.

The best idea in clean code is to stop coupling domain models to implementation details like databases/the web/etc. Once you grok that, then you're in a better position to work on eliminating unnecessary coupling within the model itself. There's lots of ways to do this poorly and well. There's no process for it. That's a feature. I feel like a lot of the flak clean code gets boils down to, "I followed it dogmatically…

[deleted]

Re: “Clean” code, horrible performance

#898

Post by whstl »

overgard wrote: post #336
vore wrote: post #15

This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…

I think part of the problem with supposed "clean" code is that it tends to be a matter of opinion. Is the polymorphic version cleaner than the switch statement version? I would argue the latter is actually easier to read. There's no real reason to think "clean" code is actually clean other than anecdotes and that someone wrote it in a book, but the performance is something that can be objectively measured.

The "Clean Code" that Casey is talking about is a book and a code philosophy that was explained in depth in talks and trainings and seminars, so I would disagree that it is a matter of opinion.

Re: “Clean” code, horrible performance

#899

Post by whstl »

berkes wrote: post #764
lumb63 wrote: post #349

I don’t understand why there is still the false dichotomy between performance and speed of development/readability. Arguments on HN and in other software circles suggest performant code cannot be well organized, and that well organized code cannot be performant. That’s false. In my experience, writing the code with readability, ease of maintenance, and performance all in mind gets you 90% of each of the benefits you’…

I'd even go so far as to say that "clean" code is a requirement for performance optimization. For a loose definition of clean. Code that is unreadable, tightly coupled, untestable or just messy is much, much harder to work in than code that is readable, loosely coupled, well-tested and clean. This has been proven often and is really a no-brainer. Performance-optimizing is finding the bottleneck, then rewriting that w…

I find it funny that people keep throwing non-caps "clean" code here in this post without knowing the context, you now have "clean architecture" too, and it made it more difficult to know what you're talking about.

Clean Code is actually a book by Uncle Bob. And Clean Architecture is the name of another book by him.

What Casey is criticizing isn't "good code". He's criticizing Uncle Bob's philosophy.

Re: “Clean” code, horrible performance

#900

Post by whstl »

flavius29663 wrote: post #240

One of the the points of "clean code" is to make it easy to find the hotspots and optimize those. Write the codebase at a very high level, plenty of abstractions etc. and then optimize the 1% that really needs it. Optimizing a small piece of software is not going again clean code, on the contrary, it re-enforces it: you can spend the time to optimize only what is necessary.

"One of the the points of "clean code" is to make it easy to find the hotspots and optimize those"

Where is this in the book? I can't find a single mention of "hotspot" in the book, and even "optimizations" only shows up 3 times.

Post reply on HN