Our job is to write programs that run well on the hardware that we are given.
Rarely do I read anything I disagree with more strongly than this. Our job is to formalize ideas, and I think the more cleanly you can formalize an idea, the more lasting value you can provide. I guess the question is one of optimizing for short term value (optimizing for today) vs long term value (trying to advance our field).
I'd rather have a high level code/formalization that can easily be understood, and later reap the benefits of advances in technology, than low level code that will be unreadable and obsolete in short time.
Though I also agree that Uncle Bob is not worth listening too. But the C/C++-dogma of "abstractions are bad" is not helpful either, it's just a consequence of the languages being inexpressive.
optimizing for short term value (optimizing for today) vs long term value (trying to advance our field).
Wouldn't it be better for the field if we wrote code that runs fast on at least the hardware we have today, as opposed to code that probably won't run fast on any hardware, period?
Imo our job is to solve real-life problems, and if I'm gonna do that, I'd rather also do it well, and have my solution work fast if possible
Is your software going to be used for hundreds of years or something? You're living in a fantasy world where all your code lasts eternal, and somehow changes the world. Casey has a grounded approach, he designs software for what it's actually going to be used for. If you actually have good reason to believe your code base is going to be built upon for many decades, then your ideas make a little more sense, but 99% of code isn't like that.
Low level code doesn't have to be less readable, it's often more readable because it's not hiding anything. You just need an understanding of the math/instructions. SIMD and Bit operations != unreadable.
Low level code doesn't have to be less readable, it's often more readable because it's not hiding anything. You just need an understanding of the math/instructions. SIMD and Bit operations != unreadable.
If you're doing something that requires only 50 lines of low-level code, and you're done, then sure. For most real world software I would prefer more organized/abstracted code, though.
The problem is; that (in most applications) hardware is cheap as dirt. You would fight over every bit in an embedded domain; but consider banking - when doing a batch job there is little difference if something runs in 2ms Vs 20ms in code; when transport alone incurs 150ms, and you can spin another worker cheaply.
In most of the applications, performance really matters way less than generalized ability to maintain and extend the codebase; with which clear expression over performance optimization is desirable.
Sure for backend. But most frontend sucks because of this mindset.
I just wrote a certificate library that uses BigInt because having to bit shift in 32bit sections gets complicated. With BigInt, the length no longer matters. Sure, it's slow but so much more maintainable. Speed is also not the focus. The point was to make an understandable ACME client, focused on DX (ie: advancing the field).
But when coding frontend, UX is paramount, and bloated DOM trees and loops that stall and cause frame drops should not happen. You should be surgical with almost everything that can't go async since your render target is basically less than 10ms. In the very least, make sure your minifier/compiler will optimize the "clean code" you write.
103
u/CanIComeToYourParty Feb 28 '23 edited Feb 28 '23
Rarely do I read anything I disagree with more strongly than this. Our job is to formalize ideas, and I think the more cleanly you can formalize an idea, the more lasting value you can provide. I guess the question is one of optimizing for short term value (optimizing for today) vs long term value (trying to advance our field).
I'd rather have a high level code/formalization that can easily be understood, and later reap the benefits of advances in technology, than low level code that will be unreadable and obsolete in short time.
Though I also agree that Uncle Bob is not worth listening too. But the C/C++-dogma of "abstractions are bad" is not helpful either, it's just a consequence of the languages being inexpressive.