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

121–130 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#121

Post by dsego »

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…

> invert the normal array-of-structs to a struct of arrays

We need our languages and compilers to give us the necessary tools to abstract away complexity without losing performance, which our current OOP languages don't really do.

Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA.

https://pixeldroid.com/jailang/overview/Features/SOA/#/overv...

Re: “Clean Code, Horrible Performance” Discussion

#122

Post by mablopoule »

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?

"The pragmatic Programmer" is one I would recommend.

That, and "Team Geek", in term of relationship with codes and teammates.

Re: “Clean Code, Horrible Performance” Discussion

#123

Post by dsego »

kilgnad wrote: post #19

Here's another controversial opinion: It's the genius programmers who write the shittiest code. In my experience clean code tends to be a waste of time for geniuses because shitty code isn't really a problem for smarter people. The further away you are from genius the greater the tendency for you to write cleaner code because you need it in order to deal with the complexity. What's common among HN readers is that the…

I've come to the same conclusion, really smart people who write compilers, name their variables one single letter and the like (the extreme variant) etc., they can actually see the matrix beyond the funny characters on the screen, they have the capacity and attention to understand the messy bits without having to make it neat, those three nested for-loops inside multiple conditionals don't bother them, they can quickly visually parse difficult code without refactoring and sectioning it off. On the opposite side, there some like me who are deficient in that regard, so I spend my time pimping my code to look nice, nit-picking on syntax style, eliminating else-clauses, trivial stuff like that.

Re: “Clean Code, Horrible Performance” Discussion

#124

Post by [deleted] »

asddubs wrote: post #53
CraigJPerry wrote: post #47

Earlier quoted context omitted.

Not the OP but HTDPv2 is a solid recommendation here

I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym. For those wondering, "How to Design Programs"

[deleted]

Re: “Clean Code, Horrible Performance” Discussion

#125

Post by dsego »

laserlight wrote: post #102
pkolaczk wrote: post #95

Earlier quoted context omitted.

Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

Afaik, data-oriented approach doesn't use classes to encapsulate behavior.

Re: “Clean Code, Horrible Performance” Discussion

#126

Post by dns_snek »

tsimionescu wrote: post #112
kaba0 wrote: post #80

Earlier quoted context omitted.

But that is explicitly known by the type, we are not writing 90s era microsoft office (hungarian notation really should not be used).

The name of a variable is supposed to contain the most relevant information someone needs when looking at an expression. If the most relevant information is the type, then that should be name. The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was. Imagine you see some code masking the first 40 bits from the location pointed to by first_item…

> The fact that the compiler knows the type doesn't help me understand the code if I have to scroll two screens up to see what it was.

Doesn't your IDE allow you to effortlessly see the type of a variable, either through inline hints, some sort of keyboard shortcut or at the very least, by hovering your mouse over it?

Admittedly I haven't professionally worked in C/C++ since university, but my understanding is that small functions can be (are?) inlined, removing the function call overhead. If that's the case, couldn't you write a 1-line function like "maskMantissa", which would clearly communicate what the code is doing without overhead?

Re: “Clean Code, Horrible Performance” Discussion

#127

Post by laserlight »

pkolaczk wrote: post #114
laserlight wrote: post #102

Earlier quoted context omitted.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

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?

Re: “Clean Code, Horrible Performance” Discussion

#128

Post by [deleted] »

goto11 wrote: post #94
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…

As an old-timer it is easy to forget that we all started as beginners and had to learn all the things which now are second nature to us. At some point the material which is valuable to a beginner seems trite, obvious and simplistic to a senior.

[deleted]

Re: “Clean Code, Horrible Performance” Discussion

#129

Post by kgeist »

wirrbel wrote: post #31
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…

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…

Just yesterday, when discussing our company's grades, someone joked that the difference between a junior and a senior developer is that a junior developer should learn to know when to use OOP/abstractions while a senior developer should learn to recognize when OOP/abstractions are to be avoided.

Re: “Clean Code, Horrible Performance” Discussion

#130

Post by stuaxo »

Yeah, not a fan of atomising code into so many classes as Clean Code recommends, the mental load is higher and its a lot harder to see what's happening.

And thata before considering the great analysis of the examples in this book from a few years ago, that showed that they don't conform to the clean code philosophy at all.

Lucky for me, I bought this and procrastinated so long about reading it, I've since found out it's not good, so I saved some time.

Post reply on HN