Earlier quoted context omitted.
If you want a spoilery TLDR: It's more about the journey. He tracks down the origin, finds the support, finds the support flawed, and leaves you to your own conclusion rather than make a new flawed one. The basic idea is that the origin assumes a highly critical inner hot loop, don't assume where it is, and optimize there. There's some other time spent saying this justifies slower abstractions for maintainability els…
Another point I liked was that there was, apparently, an influential book called Structured Programming, whose content was so universally agreed upon, that all programming became Structured Programming. Nobody needs the book anymore.
Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
141–150 of 229 posts
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#142Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#143What I don't understand with both Muratori/Blow is that they seem to be incredulous that someone wouldn't just make software high quality and fast for the sake of it Like they can't comprehend the fact that these things only happen if there is an incentive for it I think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a game They are so used…
I think the thesis would be there's a colossal structural/market failure in software. This because of many degrees of freedom, consumer ignorance, network effects and such. Compare this to physical things. The difference between the absolutely shoddiest couch sellable and the practically best one is tiny, compared to the difference between the worst software you could impose on the market and what could be achieved by competent engineers if we somehow removed the wrong incentives from capital and bureaucracy. With most software most people use, we are near the bottom of this range. I don't know if I fully buy that, even if we completely ignore whether removing these incentives is at all realistic. But would also say there's something there.
Then we can talk about how we all pay the increased cost in energy and materials, and so forth.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#144Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#145Earlier quoted context omitted.
Maybe go for a long drive? Long walk? Whatever floats your boat. I used to do manual labor and I would work my way through like eight hours of audiobooks per day.
I've noticed after I've switched to audiobooks that my retention is horrible compared to reading. For actual complex topics, it's even worse.
It's likely the same for me, but I tend to relisten to audiobooks I like, sometimes dozens of times. I have a hard time focusing on physical books, and I've probably only re-read a handful of them, so the net effect is that I take in more with a good audiobook.
I would like to learn to focus... (https://youtu.be/1IRn8BN3Qhw?t=331)
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#146Earlier quoted context omitted.
So, I have never seen anyone actually use GOTOs, so maybe a lot of the stigma comes from excessive, poor usage or something. However, having written a good chunk of ASM in my life. I don't think jumps or branches are really that hard to follow. Jumps/Branches and GOTOs specify the next location. It is not as though one has to guess where. It's not the arrow, it's the archer that is the problem.
Never as in, in BASIC, or you've never seen goto in C? The de-fanged C "goto" is all over the place in Linux and in similar close-to-metal C software. C does not (yet, likely C2Y will fix this) have labelled break, so goto is used to say "I am inside a mess of nested loops, we're done, end the loops" and as a catch-all failure handler in some codebases. My guess is that your ASM is inflected by structured programming…
To be honest, I do not have much experience with C nor BASIC. I only know the extreme basics of C, and I have never written a line of BASIC in my entire life. My first real exposure to programming was in high school (Java). From there, I basically went from high-level languages -> x86 -> high-level languages again -> starting to play with AArch64 in an attempt to but some grooves back in my smooth brain.
> My guess is that your ASM is inflected by structured programming everywhere.
I am not certain what you mean.
> if you go back 60+ years there is some scary code that even today's optimizers probably wouldn't emit because it's too crazy.
Why was this as common as the allegations lead me to believe? Was it just a product of time? No better way to handle such logic at the time?
As for your example, I know it is intended to be interpreted trivially, but I just want to clarify I understand you correctly. Is the issue due to locate-horizon depending on logic from a completely orthogonal operation?
If so, I see the red flag immediately. However, I do not see an issue with creating a separate function. I'd just have to be damn sure H was not storing anything used for some other upcoming operation prior to the function call, I'd check F and C for valid state (if necessary), take other potential side-effects into account, etc.
It feels a lot like the DRY advice being abused in higher-level languages, you know? I agree with expression, "duplication is better than the wrong abstraction."
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#147Earlier quoted context omitted.
I've noticed after I've switched to audiobooks that my retention is horrible compared to reading. For actual complex topics, it's even worse.
It's likely the same for me, but I tend to relisten to audiobooks I like, sometimes dozens of times. I have a hard time focusing on physical books, and I've probably only re-read a handful of them, so the net effect is that I take in more with a good audiobook. I would like to learn to focus... ( https://youtu.be/1IRn8BN3Qhw?t=331 )
Haha.
I used read a lot of books when I was younger, then slowly stopped, and found getting back to reading quite hard as well. Armed with the knowledge that I used to be able to do this, I just forced myself to. And after a while, I found I had no trouble committing any more.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#148Terrific presentation. But I have a comment: His dismissal of the argument Knuth makes regarding the hot loops could have been explored a bit better. I found it weird he didn’t mention the difference of types of programs of then vs now. Even today, in scientific code it is still absolutely the case a lot of the time that a huge chunk of the runtime comes from a single very very hot loop. It might be hidden in a libra…
Being I/O bound is usually a result of bad engineering practices though. If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare, or more likely that your code is so unoptimised that barely any computation gets carried out while your code is waiting on memory/disk/network. "I can't do anything because my program is I/O-bound" is more of an excuse / menta…
Plenty of scientific simulations end up being IO or communications bound when at scale (e.g. 30k CPU cores). Can hide latency to a certain degree but basically any algorithm that uses timestepping must halt at some point to allow data to flow around the nodes, or to dump data to disk for visualisation or checkpointing.
In saying that there are some novel and very clever algorithms that continue on without seemingly necessary boundary data, that then self correct when the data comes through, thus completely hiding the latency at the cost (in both accuracy and time) of running a correction process.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#149Earlier quoted context omitted.
Never as in, in BASIC, or you've never seen goto in C? The de-fanged C "goto" is all over the place in Linux and in similar close-to-metal C software. C does not (yet, likely C2Y will fix this) have labelled break, so goto is used to say "I am inside a mess of nested loops, we're done, end the loops" and as a catch-all failure handler in some codebases. My guess is that your ASM is inflected by structured programming…
> My guess is that your ASM is inflected by structured programming everywhere. I think you're probably right. To expand on this: In asm, you can have things that are clearly functions. You have a stack discipline going in and out of them. They end with stack cleanup, then a RET or some such, which pops the return address off of the stack and jumps to it. Within that function, you have JMP instructions (or whatever) t…
I have no idea what the parent meant by, "My guess is that your ASM is inflected by structured programming everywhere."
(I am the GP)
Your response was far better than mine. If those instructions were executed more than a couple of times and the constraints/assertions were identical, I'd absolutely throw them in a function. I'll handle what I need to before/after the function.
I would never branch to some coincidental label. That is why I love ASM so much. If you are sloppy or lazy, you will most likely be punished severely for those choices.
(Tangential, but when I first learned ASM in college, I felt like I learned more in that one semester than all the sum of all classes in my entire degree.)
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#150I think I kept skipping each 5 minutes until I got to something interesting and then was at the end of the video. What is his point?