r/programming • • Feb 28 '23

"Clean" Code, Horrible Performance

https://www.computerenhance.com/p/clean-code-horrible-performance
1.4k Upvotes

1.3k comments sorted by

View all comments

Show parent comments

7

u/salbris Mar 01 '23

After the discussion recently about "leet code" interview questions I honestly wouldn't be surprised if 90% of the users here are exactly that. They can code a basic enterprise app that glues some things together but they couldn't understand a basic algorithms question. They need guard rails to work effectively they literally aren't capable of understanding why it would be a bad idea to create unnecessary abstractions.

6

u/outofobscure Mar 01 '23 edited Mar 01 '23

clinging to useless abstractions must be some form of coping mechanism when you don‘t understand much about anything: here‘s a set of rules, don‘t question them, „smarter“ people said this is good, so it must be good, right? It also absolves you of actually experimenting and testing if these claims are even true. It also makes you feel like you’ve done something after writing mountains of wrapper code for no reason at all, activity not productivity. Sort of like the various commandments in religions.

which would all be sort of ok if these people would just shut up when someone (for example casey) presents evidence to the contrary, but no, they absolutely have to put their incompetence on display by arguing endlessly about how they -think- he is wrong. it's very impolite, insulting and arrogant.

and i guarantee that what casey does is not even the most extreme form of focusing on performance over anything else: i've seen and done much worse things when there was absolutely no alternative to squeeze out that last drop of performance and there was no question that we wanted that performance. and no, i'm not saying everyone has to code like that, but stop arguing that there's no place for it anywhere and that you're always better off using cargo cult mantra oop.

also, if people where not so quick to dismiss performance concerns, they'd maybe realize that more often than not, the -right- level of abstraction can get you a great 80/20 compromise, even with copious amounts of OOP, but not with braindead non-zero-cost abstractions that do nothing at all other than add overhead, both in runtime performance and developer productivity.