I don't like most of these "principles", as anyone can verify by looking at my previous comments, but this article is cherry-picking to its utmost level of unfairness. These "clean code" principles should not, and generally are not, ever used at performance critical code, in particular computer graphics. I've never seen anyone seriously try to write computer graphics while "keeping functions small" and "not mixing le…
Yeah, but why is good and fast opposite rather than orthogonal? Why languages and compilers are not built so at least we can do both. Or even better, why is good and fast not the same thing in computer languages?
> Our job is to write programs that run well on the hardware that we are given. I actually believe "the hardware that we are given" is the entire root of the problem. Most programmers work and test using whatever hardware is current at the time, but this is makes them blind to possible performance issues. Take whatever you're working on, and run it on the hardware of 5-10 years ago. If you still have a good experienc…
I don't think the "job description" is accurate though. Most programmer's jobs is to write code that runs well _enough_ on the hardware that we are given. What "well enough" means depends heavily on whether you are working on firmware, a game engine or a web application. If performance isn't important, you end up with slow software.
Apart from performance, I find that "non-clean" code (in terms of the article) is sometimes easier to understand, reason about and maintain. Context is important of cause...
Yea, me too. I don't really understand people that say that clean code is easier to understand.
I think the sentiment is that order and organisation is helpful in achieving goals and cultivating a good working environment as opposed to a big mess. Analogies, just like abstractions, are leaky.
Yeah, but this one leaks a smart-matter paint that self-assembles into a shape of text saying "the order and organization is not the goal, but a consequence of ruthlessly optimizing for performance above all".
I didn't try to say that, but maybe I confused my point with the analogy (like an earlier comment mentioned: they're imperfect).
I meant to say that organisation helps make work easier, including adding performance optimisations.
The thing that sets him off is that he is using a computer with enormous computing power and everything is slow. He does have a narrow view, but it does not make his claims invalid. I liked that his POC terminal made in anger made the Windows Terminal faster. But even in that context it was clear that by making some tradeoffs - which the Windows Terminal team can not make (99.99% of users do not run into the issue, b…
> The thing that sets him off is that he is using a computer with enormous computing power and everything is slow. If that's his complaint, then "clean code" isn't the problem. The problem is capitalism and/or human nature. Once something performs acceptably well, ie good enough to sell it, performance isn't going to get any better. Flashy stuff and features get you money, going from 400ms to 100ms gets you...nothing…
In shared code particularly with a culture of refactoring, there's no guarantee that the function call you see is doing what you remember it doing a year ago. When I was coming up I got gifted a bunch of modules at several jobs because the original writer couldn't be arsed to keep up with the many incremental changes I'd been making. They had a mentality that code was meant to be memorized instead of explored, and I…
> there's no guarantee that the function call you see is doing what you remember it doing a year ago. TDD provides those guarantees. If someone changes the behaviour of the function you will soon know about it. That's significant because Robert 'Clean' Martin sells clean code as a solution to some of the problems that TDD creates. If you reject TDD, clean code has no relevance to your codebase. As Casey does not seem…
You seem to ignore that when the unit changes, the tests do too. If you come back a year later, foo.bar.baz(quux) might have been refactored and lazily so. The tests were also updated and still pass. You may jump into the code only to realize that someone no-op'd everything and never removed call sites. TDD is primarily a design tool, not a lock-into-implementation tool.
>The compiler not catching it is a limitation of the language he uses, not the limitation of the general concept of switch / pattern matching. Scala, Haskell, Rust do catch those. You're thinking of defaultless switch statements. Rust and Typescript catch those issues as long as you don't add a default. I'd already thought of it when I typed it >And who said you'd ever need to add a new shape? ô_o >Maybe you will nee…
> You're thinking of defaultless switch statements. Rust and Typescript catch those issues as long as you don't add a default. I'd already thought of it when I typed it But the same problem exists with interfaces and virtual dispatch! If you provide a default implementation at the interface / abstract class level, then the compiler won't tell you forgot to implement that method, because it would see the default one e…
Default implementations at the interface level, wow, apparently it's a thing in Java. I don't think it's in C++.
I've worked in projects where no one seemed to know SQL, where massive speed improvements were made by fixing very low hanging fruits like removing select * queries, adding naive indexes, removing N+1 queries etc. Likewise, I've worked in code bases where performance had been dreadful, yet there were no obvious bottlenecks. Little by little, replacing iterators with loops, objects/closures with enum-backed structs/ta…
> adding naive indexes
You get 90% of the improvement just from that.
Indexes are the whole reason anyone even uses databases. And yet some backend guys think they are optional.
His classes are doing a single multiplication, of course dynamic dispatch would have a significant cost in this scenario.
Never look at the dispatch of a big company’s Java code base then. It’s dynamic dispatch 400 layers deep for a single network call or file op or small amount of math. Sure those are more expensive operations, but the dynamic dispatch has continually out scaled the problem.
But the company that uses Java quite often is writing the umpteenth line-of-business application, where dynamic dispatch is not going to cause a massive overhead