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

161–170 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#161

Post by Measter »

dsego wrote: post #121
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...

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

I believe Zig has a stdlib function that allows you to do this, and I'm pretty sure there's also a Rust crate that provides a proc macro for it.

Re: “Clean Code, Horrible Performance” Discussion

#162

Post by oreally »

Barrin92 wrote: post #7

The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so mu…

I wouldn't go down that line. There is code that makes you -think- it's safer but all it really does is add more needless complexity. It's one of those things where the 'safety' result hasn't really been given a good measurement.

Re: “Clean Code, Horrible Performance” Discussion

#163

Post by alpaca128 »

thethirdone wrote: post #18
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…

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…

> Most modern programmers have never done the "optimization" that Knuth was referring to in 1974

I don't know the exact boundaries of what Knuth meant, but there definitely is a kind of "premature optimization" which has nothing to do with squeezing out the last nanoseconds at a low level. When writing code it often feels like a good idea to make it reasonably efficient or flexible from the start, for example by using more specialized datastructures or creating more abstractions which makes the code using them a bit less straightforward. In my experience this usually backfires and only means I spent more time writing code before discarding the first iteration.

At first glance this is a different kind of optimization but the outcome is the same and so I think Knuth's famous quote can still be applied. Other than that I agree, optimization at the degree e.g. Casey Muratori made in the video referenced in this post is only relevant in tiny hotspots if at all.

Re: “Clean Code, Horrible Performance” Discussion

#164

Post by gofreddygo »

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 think of this as a cross spectrum (terrible, good enough, well done, overdone)

I've seen less production code and more discussions on code that focusses on opposite ends.

terrible readability and maintainability with extreme performance.

v/s.

terrible performance with overdone "design" abstractions.

OTOH, I've seen lot of production code that has good enough design, with well done perf and vice verse.

Not much talk about that stuff.

Re: “Clean Code, Horrible Performance” Discussion

#165

Post by xnx »

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…

Like "Reduce. Reuse. Recycle." The logic behind "Make It Work. Make It Right. Make It Fast." is very deliberate.

Re: “Clean Code, Horrible Performance” Discussion

#166

Post by z3t4 »

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 want to add reusability and removability. If I for example write some code that connects to a SMTP server to send an e-mail, I probably will re-use it in other places, even in other programs, so the code can't depend on global functions. The code should be independent. Then it also becomes removable and replaceable.

Re: “Clean Code, Horrible Performance” Discussion

#167

Post by ketzu »

dsego wrote: post #97
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've seen examples of FizzBuzz Enterprise in practice, eg a small algorithmic challenge that reads in some data and finds a value was split into several files, one class to read the data, one class to run the algorithm, one file to print out the results, etc etc. What was supposed to be one function with less than 50 lines turned into a multi-class multi-file monstrosity. The Java coder doing it couldn't imagine doin…

> a small algorithmic challenge

For me that depends on the context:

* A challenge for an interview? No wonder people try to insert structure as if it were a bigger project.

* A challenge for a contest? Probably not a good solultion for most point systems.

* A challenge for fun on hackerrank or LC? Whatever you feel comfortable with works.

For structuring a larger system, separating data ingestion, data output and algorithm to work on the data, seems like a fairly entry level separation.

Re: “Clean Code, Horrible Performance” Discussion

#168

Post by bqmjjx0kac »

dceddia wrote: post #153
inimino wrote: post #54

Earlier quoted context omitted.

Since this gets repeated so often, it is probably worth reproducing a little more of Knuth's quote. "There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We shoul…

Much like Chuck Norris references in movies from 2004, I get the sense that this advice is a product of its time. One of those “it makes more sense if you were there” things. (It even starts off acknowledging that it’s an article about current trends!) Not to say it doesn’t generally still hold true, but this part stuck out to me: > Programmers waste enormous amounts of time thinking about, or worrying about, the spe…

> I don’t think this is widely true today (outside e.g. game development anyway). If it were, we’d probably have lots of fast software that’s very hard to read!

I think the point was that programmers' intuition about performance is wrong. So we'd wind up with a lot of slow, buggy software — buggy because the code became hard to read when it was prematurely optimized.

Re: “Clean Code, Horrible Performance” Discussion

#169

Post by giraffe_lady »

kgeist wrote: post #129
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…

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.

Used to be a similar joke in frontend a few years ago when css was at its complexity peak. Where the progression is junior: "I'll just use bootstrap", mid: "I'll write my own css custom tailored to the project", senior: "I'll just use bootstrap."

I also think some of this... attitude? learning? is what go is trying to activate/take advantage of. Everywhere I've worked has had some monstrously experienced senior dev who could easily crack out a solution to a problem of any difficulty but who refuses to use any abstraction more sophisticated than a for loop.

Go says you don't need anything more sophisticated than a for loop, in fact you can't have anything more sophisticated than a for loop. I guess I'm not there yet but it definitely seems suspicious that the people I know who are most into go are very early in their careers or deeply experienced.

Re: “Clean Code, Horrible Performance” Discussion

#170

Post by waynesonfire »

tome wrote: post #140
namaria wrote: post #61

Earlier quoted context omitted.

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

Very cool point.

I will highlight though that I have worked with people that choose the path of least resistance regardless of complexity of the code that would need to be changed. It's as if they refuse to read code.

Post reply on HN