I love this video because it's a long-missing counter to Clean Code. In the software world, often someone makes a bold claim (like "clojure considered harmful") and someone rebuts it ("a response to 'clojure considered harmful'") and someone rebuts the rebuttal ("a response to 'a response to «clojure considered harmful»'"). Sure, we've had people criticize Clean Code before, but never a proper critique.
“Clean Code, Horrible Performance” Discussion
191–200 of 220 posts
Re: “Clean Code, Horrible Performance” Discussion
#192Earlier 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
How are structs in Rust any different than classes?
Re: “Clean Code, Horrible Performance” Discussion
#193Earlier quoted context omitted.
I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.
Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre , is of course the reason behind this. I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.
Snake-oil salesmen have always existed in one form or another.
OOP was pushed very strongly in the 90s, for example, and people promising to create massive increases in productivity by providing consulting services for "OOP-ifying" code probably made plenty of $$$ off that fad.
Re: “Clean Code, Horrible Performance” Discussion
#194Earlier quoted context omitted.
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.
Of course it detracts from your argument, because your argument is using it as evidence that clean code is not good for performance.
No, Casey’s argument is that clean code is not good for performance. The counter-argument to Casey’s argument is that when performance matters, don’t write clean. My counter-counter-argument to the counter-argument to Casey’s argument is that performance is clearly missing even when it matters, so clearly developers aren’t able to figure out when performance matters, so the counter-argument won’t work.
Bob is saying:
doCleanCode()
// doUglyFastCode()
// doCleanCode()
doUglyFastCode()
if (performanceMatters()) {
// doCleanCode()
doUglyFastCode()
}
else {
doCleanCode()
// doUglyFastCode()
}
You’re objecting that I don’t know the bad performance in a given case is because of a `doCleanCode` call, I haven’t looked at the source, it could very well be for other reasons:
if(performanceMatters()) {
doDirectDrawToScreen()
}
else {
doDispatchDebouncedStateChangeToUserInterfaceFramework()
}
Re: “Clean Code, Horrible Performance” Discussion
#195This is the second critical thread about Uncle Bob in the last month or so. (Maybe there have been more.)
Why digging at ancient books? Is there something going on here?
Re: “Clean Code, Horrible Performance” Discussion
#196I have a problem with software engineering use of the qualifiers “clean”, “simple”, “easy”, “decoupled”, “elegant”, among others that only appeal to aesthetic sense but are not quantified at any moment.
Re: “Clean Code, Horrible Performance” Discussion
#197Simple > Complex. Every extra year I spend in engineering, it's becoming clear that this is actually one of the only few things that mattered in the long run. I would say this is one of the best if not the best advice in programming and even in life. If clean code doesn't follow that, ditch.
What you say makes a lot of sense. Now, to give a concrete example. There was a C++ PR introducing an interface taking an argument of type int representing a duration. I suggested using std::chrono::duration ( https://en.cppreference.com/w/cpp/chrono/duration ), and I was overruled on the basis that "an int is simpler". To have context if you are not too familiar with C++: - std::chrono::duration is part of the C++ s…
Simple vs Complex should always be evaluated holistically.
Each file could be simple but if they are in 5 level of inheritance, then it's not simple as a whole. Same with 10 different way to do the same thing or 3 different class that can be used to the same effect, it's not.
Your case is clearly adding complexity as the new class have no reason of existence, as it's just rebuilding part of the standard library which your compiler would likely have included anyways. The suggestion is clearly a bad one but our industry is filled with people who are either incapable of adequately applying "Simple > Complex" or don't believe in it. That's why enteprise FizzBuzz exist.
Re: “Clean Code, Horrible Performance” Discussion
#198It 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…
This is pretty much my soapbox about DRY. Code is like clay, once it dries it’s not malleable anymore. Components that copy/paste but in doing so are self-contained can be fearlessly changed.
And above a certain size dry works against you because when making changes to component A that requires a slight modification of the behavior or component Q deep in the call stack is so painful because the blast radius is huge. Dry codebases end up slowly accumulating more and more effectively read-only code that makes implementing non-trivial changes require increasing amounts of cleverness until development slows.
I think the more general principle is more to do with code directionality and framework vs library but the motivation to franken-framework your code always seems to be dry.
Re: “Clean Code, Horrible Performance” Discussion
#199Earlier quoted context omitted.
Surprise: I don't use classes. Rust doesn't have them. :P
How are structs in Rust any different than classes?
Behavior and data is more separated
A struct only contains data, however you e.g. can define methods on it or implement traits for it No inheritance.
Re: “Clean Code, Horrible Performance” Discussion
#200I 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…
Also, I feel, it's a whole lot easier to refactor "clean" or "readable" code for performance than the other way around. Make it run. Make it clean. (and if need be,) Make it fast.
As a dark matter developer, I learnt it as:
Make it work
Make it right
Make it fast
My interpretation of this, so far, "make it right", is to make the code and design cleaner and refactor.
Then "make it fast" came into the play, iff, there was enough push.