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

141–150 of 932 posts

Re: “Clean” code, horrible performance

#141

Post by Tenticles »

sebstefan wrote: post #105
pkolaczk wrote: post #101

Earlier quoted context omitted.

> With his version you have to add a new `case` to every switch statement and hope you didn't miss one with a default case, because the compiler won't catch it. The compiler not catching it is a limitation of the language he uses, not the limitation of the general concept of switch / pattern matching. Scala, Haskell, Rust do catch those. > If you follow the principle "switch statements over [X]", try to add a new sha…

>The compiler not catching it is a limitation of the language he uses, not the limitation of the general concept of switch / pattern matching. Scala, Haskell, Rust do catch those. You're thinking of defaultless switch statements. Rust and Typescript catch those issues as long as you don't add a default. I'd already thought of it when I typed it >And who said you'd ever need to add a new shape? ô_o >Maybe you will nee…

You are not safe from a colleague adding a dozen classes to add two numbers if you are enabling the "clean" crowd either. When I was at uni I was obsessed with these clean ideas and how they would allow big teams to work. after years of working I have seen these ideas fail to actually make teams work in an harmonious manner, worst hit I have experienced against these ideologies was finally working in a place without them and seeing how a lot of the alleged "advantages" of "clean code" could be achieved by other simpler means and how much in the way these ideologies are of actually being productive.

Productivity is achieved in spite of clean, not thanks to it.

Re: “Clean” code, horrible performance

#142

Post by sebstefan »

Tenticles wrote: post #141
sebstefan wrote: post #105

Earlier quoted context omitted.

>The compiler not catching it is a limitation of the language he uses, not the limitation of the general concept of switch / pattern matching. Scala, Haskell, Rust do catch those. You're thinking of defaultless switch statements. Rust and Typescript catch those issues as long as you don't add a default. I'd already thought of it when I typed it >And who said you'd ever need to add a new shape? ô_o >Maybe you will nee…

You are not safe from a colleague adding a dozen classes to add two numbers if you are enabling the "clean" crowd either. When I was at uni I was obsessed with these clean ideas and how they would allow big teams to work. after years of working I have seen these ideas fail to actually make teams work in an harmonious manner, worst hit I have experienced against these ideologies was finally working in a place without…

>You are not safe from a colleague adding a dozen classes to add two numbers

The difference is, adding "default" cases to complete switch statements happens all the time, you've probably witnessed it, I know I have, whereas colleagues adding a dozen classes to add two numbers doesn't.

You're also never safe from meteorites crashing your building, let's talk about real antipatterns

Re: “Clean” code, horrible performance

#143

Post by dvaletin »

KyeRussell wrote: post #125
dvaletin wrote: post #44

Earlier quoted context omitted.

> Even worse, the more concepts and abstractions you apply to your code the better programmer you are! I had an Android programmer, who was eager to write clean code following GOF patterns, OP and the rest of the fancy things senior developers usually do. Ended up Android team with 3 devs required 3x time to develop same feature compared to single iOS engineer.

Well they weren’t a good senior developer then. Part of the art is knowing when to use the patterns. An incredibly im protest differentiation as it’s so so easy for someone a bit green behind the ears to see this and think that any sort of architectural thinking is useless.

> Well they weren’t a good senior developer then. He wasn't. He was a mid grade dev, but it does not important, because even sr devs can fall in love with overcomplications.

Re: “Clean” code, horrible performance

#144

Post by sebstefan »

Tenticles wrote: post #124
sebstefan wrote: post #94

Earlier quoted context omitted.

>I don't find Casey's performant version less readable It does create implicit coupling. If you try to add a new shape you will run into the problem. In the clean code version, your compiler will remind you to implement calculateArea With his version you have to add a new `case` to every switch statement and hope you didn't miss one with a default case, because the compiler won't catch this one. It's a crap way to co…

people using clean code ideologies are being prematurely pessimistic and assuming they know much more about a problem than they actually do when they use these clean code techniques. "I don't know how many shapes I've been asked to do, so I'll assume the worst case scenario and make the code slower and harder than the simple naïve solution that would be hard to read(debatable) if we had one million shapes" is a terri…

It doesn't have to be slow. There's a reason "Clean code" is being criticized everytime it's mentioned. It touts inheritance and polymorphism as a solution to everything like it's 2002. There's been enough "Inheritance considered harmful" articles to toss that aside

The take on switch statements is covered in "The Pragmatic programmer" as well, which coincidentally is much less criticized when it comes to books about clean code.

The way to fix the switch is getting rid of the class "shape" and making it an interface, then implementing the interface in each shape, as a non-virtual method. And then you don't let people inherit. They can compose instead.

Performance is unaffected, you get rid of the switch, the compiler catches your mistakes for you, and everyone's happy

Re: “Clean” code, horrible performance

#145

Post by rileymat2 »

rafabulsing wrote: post #103
juliangmp wrote: post #57

This example exists in such a vacuum and is so distant from real software tasks that I just have to shake my head at the "clean code is undoing 12 years of hardware evolution"

It's an example from the Clean Code book itself, though?

It is, but that's the catch. It would be exceedingly hard to provide understandable examples of these things in code that is complex enough to need the patterns.

Re: “Clean” code, horrible performance

#146

Post by MonkeyClub »

cinntaile wrote: post #86
MonkeyClub wrote: post #77

Earlier quoted context omitted.

Not just that. The “developer time is valuable” mantra is thrown left and right, disregarding how much of that valuable resource will be wasted down the line due to bad implementations. If we optimize for developer time, let’s optimize across the software’s entire lifecycle, not just that first push of a MVP to production.

This is a good point but it gets complicated as you often don't know the software's entire lifecycle so you have to optimize for something slightly different.

Yep, I think you’re right.

We just need to do away with shoddy first implementations, while avoiding premature optimization (or pointless perfectionism).

Which is all good in theory. In practice, management needs to also acquiesce and stop with the impossible deadlines.

I mean, I’ve worked on more than one projects that were sold to clients before they were implemented, and I think I’m not unique in that :)

Re: “Clean” code, horrible performance

#147

Post by readthenotes1 »

"it is easier to make working code fast than to make fast code work"

That was from either the 1960s or the 1970s and I don't know that anything has changed in the human ability to read a mangled mess of someone's premature optimizations.

"Make it work. Make it work right. Make it work fast." how to apply the observation above...

Re: “Clean” code, horrible performance

#148

Post by rstefanic »

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…

When working with a larger code base, there will always be parts that you don't remember writing and you'll inevitably have to read the code to understand it. That's just part of the job/task, regardless of the style it's written in.

Re: “Clean” code, horrible performance

#149

Post by st3fan »

gjadi wrote: post #131
st3fan wrote: post #91

Earlier quoted context omitted.

Evidence in a micro benchmark of a single page of code. The focus on performance here ignores the fact that most programs are large systems of many things that interact with each other. That is where good design and abstractions and “clean code” can really help. Like all things it is about finding a balance and applying the right techniques to the right parts of a larger system.

I'd say that it really depends on what the code needs to do. For example, if the code is to be distributed and extended as a third-party library, then the class hierarchy is probably a better fit to allow extensibility. But if the purpose of the API is to compute the area of given shapes (as in the example), then it makes sense to make it efficient and there is no use to provide extensibility to the outside world. Th…

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

Re: “Clean” code, horrible performance

#150

Post by stunpix »

So he puts polymorphic function calls into enormous loops to simulate a heavy load with a huge amount of data to conclude "we have 20x loss in performance everywhere"? He is either a huge troll or he has a typical fallacy of premature optimization: if we would call this virtual method 1 billion times we will lose hours per day, but if we optimize it will take less than a second! The real situation: a virtual method is called only a few hundred times and is barely visible in profiling tools.

No one is working with a huge amount of data in big loops using virtual methods to take every element out of a huge dataset like he is showing. That's a false pre-position he is trying to debunk. Polymorphic classes/structs are used to represent some business logic of applications or structured data with a few hundred such objects that keep some states and a small amount of other data so they are never involved in intensive computations as he shows. In real projects, such "horrible" polymorphic calls never pop up under profiling and usually occupy a fraction of a percent overall.

Post reply on HN