Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

youtube.com

Post reply on HN
Print view View original

91–100 of 229 posts

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#91

Post by inigyou »

bena wrote: post #82
dgellow wrote: post #51

Earlier quoted context omitted.

He’s known for his Handmade hero series (unfortunately archived now) where he developed his game over 500+ episodes: https://hero.handmade.network/ I’m sure you can find bugs in the work of any game dev you would consider legendary, game implementation is generally very messy

660+ and the game was never finished

Doesn't mean you can't learn a lot from the attempt. Technical craftsmanship and project management skill are two completely separate skills. Definitely don't learn project management from Casey.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#92

Post by HexDecOctBin »

bob1029 wrote: post #78
Almondsetat wrote: post #66

Earlier quoted context omitted.

Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science and the ideas that have not yet come to fruition despite being extremely old

> Feel free to point to anyone doing these deep dives Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food. I used to spend a lot of time watching crap like lex and primagen befor…

> that I could practically apply in my daily work

When has History of any kind ever held practical value?

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#93

Post by my-next-account »

Almondsetat wrote: post #66
layla5alive wrote: post #65

Earlier quoted context omitted.

You think there aren't other people equally or more qualified? I mean Casey may be the most visible person with those qualifications - but lack of visibility doesn't imply lack of competence, plenty of brilliant people work in the background..

Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science and the ideas that have not yet come to fruition despite being extremely old

Me, I do them.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#94

Post by smj-edison »

Pannoniae wrote: post #57
tialaramex wrote: post #5

tl;dr the saying is that "premature optimisation is the root of all evil", and Casey burrows into contemporary data to show that really although the claim was 3% of the code takes up 90% of the runtime even then it was more likely 4% takes 50%. The best thing you could take away from this lecture is something a reasonable person should take away from the original "root of all evil" saying anyway. Measure. Measure. Me…

Sure, but there are performance issues no profiler will catch in a straightforward flamegraph reading. Some examples: 1. Your hottest loop is spilling registers which only shows up as non-local cache thrashing (i.e. some other random code becomes slow) or randomly slow instructions i.e. "why is this xorps to initialise this float suddenly slow" due to pipeline stalls 2. Your code stops fitting into cache due to the c…

How do you even measure those? Will that show up under something like VTune?

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#95

Post by tialaramex »

cure_42 wrote: post #71
tialaramex wrote: post #44

Earlier quoted context omitted.

It's not the focus of the talk and so it's hard to tell if Casey understands (the choice to separate the words GO TO in several places suggests he does) but the `goto` keyword you've seen in several modern languages is not the problematic "GO TO statement", it's a de-fanged remnant, the toy poodle to GO TO's wolf pack. The actual GO TO complained of is, like the jump instruction in machine code, just entirely unbothe…

Windows batch, no?

COMMAND.COM in its batch mode? Kinda, sorta. The interpreter can AIUI "call" other files but the "goto" is restricted to the same file.

So we can jump over a variable declaration which is pretty confusing, but we can't jump into unrelated code.

Also while COMMAND.COM can't be as old as BASIC it must be pretty old.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#96

Post by Almondsetat »

jddndnfnfn wrote: post #87
Almondsetat wrote: post #84

Earlier quoted context omitted.

You are making many assumptions. First of all, he is doing the deep dives by researching all those articles, and of course the resulting presentation will be very superficial. The point is exactly to publish a book to allow the reader to partake in the deep dive. Secondly, nobody said anything about applying that stuff to your daily work.

[flagged]

Thank you for creating an account just for making stuff up nobody has said or even hinted at

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#97

Post by Pannoniae »

smj-edison wrote: post #94
Pannoniae wrote: post #57

Earlier quoted context omitted.

Sure, but there are performance issues no profiler will catch in a straightforward flamegraph reading. Some examples: 1. Your hottest loop is spilling registers which only shows up as non-local cache thrashing (i.e. some other random code becomes slow) or randomly slow instructions i.e. "why is this xorps to initialise this float suddenly slow" due to pipeline stalls 2. Your code stops fitting into cache due to the c…

How do you even measure those? Will that show up under something like VTune?

Yes, VTune is good.

I'm on AMD and uProf isn't that good (it often fails to match PDB to source, it's slow / crashy, stuff like that) so I mostly use Superluminal myself (has godly UX) and only drop down to uProf when I have a suspicion and want to gather hardware stats.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#98

Post by tialaramex »

hirvi74 wrote: post #90
tialaramex wrote: post #44

Earlier quoted context omitted.

It's not the focus of the talk and so it's hard to tell if Casey understands (the choice to separate the words GO TO in several places suggests he does) but the `goto` keyword you've seen in several modern languages is not the problematic "GO TO statement", it's a de-fanged remnant, the toy poodle to GO TO's wolf pack. The actual GO TO complained of is, like the jump instruction in machine code, just entirely unbothe…

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 everywhere. Yes, unlike COME FROM we can see where we're going next with GO TO but 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. Suppose calculate-total-fuel ends with three CPU instructions which copy register F into register H then add register C to it and multiply the sum by four. Over in locate-horizon it so happens we need to add two things together and multiply them by four and we could do that last. So, if those two things were in registers F and C we could just GO TO that last part of calculate-total-fuel.

You're correct that we don't need to "guess where" it goes, but good luck understanding why the program works when it's like this, let alone the ordinary maintenance work of making small modifications.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#99

Post by spawrks »

Almondsetat wrote: post #15

I think Casey is currently the most informed person to make a series of books or articles summarizing the history of SW Engineering, all the lessons learned and forgotten, and all the good stuff that was published and still hasn't gained traction in the practice

I feel like the comments that are giving you pushback haven't actually listened to Casey before. I agree with you, while opinionated his perspective is very pragmatic and misunderstood. He's done such a great job giving his experience out to the broader world too.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#100

Post by 3eb7988a1663 »

tialaramex wrote: post #67
3eb7988a1663 wrote: post #58

Earlier quoted context omitted.

John Carmack is a legendary game programmer. If I can identify a superior algorithmic approach to something in Doom, does that disqualify Carmack's credentials?

First I think I'd want to see you identify a superior algorithm known when Doom shipped and then we can have that discussion about who's credentials should be disqualified.

I never made claims to be any kind of game programmer, but sure.

Fine, as I recall, Doom data assets are searched linearly whenever they need to pull new data. So if you switch to the chainsaw, and need to rev, the game does a linear scan of all graphics, maps, and sounds looking for the vroom noise.

There are many different data structures that could perform this lookup faster. These have been known since the earliest days of computing.

Does it matter? No. Engineering is all about trade-offs. A linear scan was obviously fast enough and simple to implement.

Similarly, if walk monster manually trolls the map, that does not say anything about Casey in isolation. I believe all of Blow's games use a custom game engine, so unless a nav mesh system was already implemented, that was going to take additional work. The walk monster may have been better bang-for-buck.

Post reply on HN