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

51–60 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#51

Post by lazyasciiart »

fwlr wrote: post #41

The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The r…

> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead

That is a giant presumption.

Re: “Clean Code, Horrible Performance” Discussion

#52

Post by FlyingSnake »

Apocryphon wrote: post #14
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…

Clean Code led to the development of the VIPER framework, which is a crime it must answer for.

True. VIPER was the craziest thing I had to deal with when I developed iOS.

Re: “Clean Code, Horrible Performance” Discussion

#53

Post by asddubs »

CraigJPerry wrote: post #47
readlikeasloth wrote: post #32

Earlier quoted context omitted.

This begs the question: what do you recommend instead?

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"

Re: “Clean Code, Horrible Performance” Discussion

#54

Post by inimino »

taeric wrote: post #21
thethirdone wrote: post #18

Earlier quoted context omitted.

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…

Knuth very much pushed for efficient code. One need only look at the code he writes, to see. Which is a large part of what makes that attribution amusing.

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 should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

"Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code, but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail."

The context for this statement, is of course his article [1] saying that goto statements should not be regarded as bad for religious reasons, but should be used appropriately. How common is the pragmatic approach to goto today, vs the "religious" response to goto?

So this is the context in which it's appropriate to quote Knuth on this: if you are thinking about efficiency all the time, making intuitive guesses about where your programs will be slow, using measurement tools after the fact, and in danger of spending your optimization efforts on 100% of the code instead of 3%, and if you have a rational rather than emotional response to seeing goto statements in your codebase, then Knuth's quote is for you. What he was really arguing for is a practical, rational approach rather than religious, emotional responses. Which was also Dijkstra's point about goto. The whole article is well worth a read if you haven't already seen it.

[1]: https://dl.acm.org/doi/pdf/10.1145/356635.356640

Re: “Clean Code, Horrible Performance” Discussion

#55

Post by Spiwux »

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 value

Re: “Clean Code, Horrible Performance” Discussion

#56

Post by kilgnad »

anchochilis wrote: post #49
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…

This was funny. But I've seen too much clean code written by people smarter than me to agree. I actually think how "clean" your code is depends on lots of factors. Eg. (a) Do you care if your coworkers find it easy to modify your code? (b) Do you feel a sense of ownership over the code you're touching? (c) Does your organization reward delivery speed without any checks for code quality? (eg. no culture of code review…

You're not dealing with the geniuses. You're likely just dealing with people smarter than you. I can assure you geniuses are rare, and people of the same intelligence level tend to gather so you can go through a career completely missing them depending on where you work. There's enough noise such that among these groups you won't notice the correlation.

Tbh the geniuses don't view their own code as shitty, to them it's quality. It's only viewed as shitty externally.

Re: “Clean Code, Horrible Performance” Discussion

#57

Post by jackblemming »

foo42 wrote: post #40
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…

that last paragraph is an excellent description of the problem!

Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.

Re: “Clean Code, Horrible Performance” Discussion

#59

Post by fwlr »

lazyasciiart wrote: post #51
fwlr wrote: post #41

The “not all parts have to be performant, so you can make those parts clean” objection never sits well with me. And it’s not just the fact that clean code is presented as universal and this claim is only introduced after you complain that clean code has made your code less performant (Casey was remarkably polite in pointing this out and Bob was very gracious in concurring, both of which were a delight to read). The r…

> the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead That is a giant presumption.

It is slow, and I presume that’s because competent developers wrote it clean. It’s quite possible that it’s not clean either and was just written by developers incapable of performance or cleanliness. That possibility doesn’t detract from my argument - there’s no point in discussing performance or clean code with them if they’re incapable of either.

Re: “Clean Code, Horrible Performance” Discussion

#60

Post by jenadine »

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…

I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like.

Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it can even be counter productive to hide details if these details are simpler than the abstraction itself.

In summary, it's all about trade-offs and not over-doing it.

Post reply on HN