10 ms·

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

326 points by surprisetalk 20d ago

kshallvari 17d ago
THE LEGENDARY GAME PROGRAMMER
- nchmy 17d ago
  Isn't that Jonathan blow? (to be clear, I'm a big fan of Casey)
  - dgellow 17d ago
    They are both legendary game programmers
    - inigyou 17d ago
      Are they? Casey programmed the walk monster for Jon's game, a brute force tester to make sure you could always walk both ways and never get stuck, instead of building the walking system using a nav mesh. There was one place you could walk where you weren't supposed to, despite the walk monster, that would have been obvious if it was a nav mesh.
      - dgellow 17d ago
        He’s known for his Handmade hero series (unfortunately archived now) where he developed his game over 500+ episodes: https://hero.handmade.network/ 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
        bena 17d ago
        660+ and the game was never finished
        inigyou 17d ago
        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.
        tialaramex 17d ago
        Sure, but the biggest reason to direct anybody to these videos is that they should actually make that video game they want to make, not just think about it - and so the fact that Handmade Hero just trails off and doesn't end up producing a finished video game is a problem. The craftsmanship is dubious. I think it's a problem that people assume Casey knows what he's doing when so often he's like "We're doing it live" and Casey's hand coded solution is pretty bad whereas the thing which came in the box is very good. Casey understands Casey's version, and that's an upside if you are Casey but you are not. If the result was a finished game then hey, whatever, the game was finished and that matters. But that part didn't happen either, so then it's just like watching Tsoding or something.
        ahaferburg 17d ago
        At some point I stopped caring about Handmade Hero because he just never got out of the global illumination rabbit hole. He should have followed that as a side quest, behind a feature flag. Maybe one week for progress on the game, one week for rendering experiments. He didn't seem to make much progress, and it just fizzled out as he ran out of steam. Finishing should have been a bit higher on the priority list. It was just not setting a good example from a project or self management perspective.
        guitarlimeo 17d ago
        Well Billy Basso was hugely inspired by the Handmade Hero series and went on to make the critically acclaimed Animal Well because of it. That's enough of a win for that series in my eyes.
        andersonpico 17d ago
      - 3eb7988a1663 17d ago
        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?
        tialaramex 17d ago
        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.
        dgellow 17d ago
        I think you’re both saying the same thing
        3eb7988a1663 17d ago
        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.
        jodrellblank 8d ago
        > "if walk monster manually trolls the map" Casey Muratori has a 50 minute video on "Killing the Walk Monster" which is about how they started looking for glitchy game geometry by pretending to be a player walking around, then by a flood-fill ("walk monster") probing for barriers, then the video is explaining how they designed something "exponentially faster" (both demonstrated starting at time 38:33). The better version was realtime enough that level designers could use its overlays interactively while working on the level, and during test playthroughs. He describes it as "exponentially faster". It doesn't seem like the earlier poster calling it "brute force" is a reasonable description. https://www.youtube.com/watch?v=YE8MVNMzpbo https://www.youtube.com/watch?v=YE8MVNMzpbo And the place the player can walk but shouldn't be able to (off the boat), is not a fault in the walk system, as explained in that video near the end, it's a place where level designers made a mistake.
  - arnorhs 17d ago
    I believe this is referencing a meme on the primeagen's standup podcast, where Casey is referred to as legendary while he feels undeserving of this title. Titles aside, his talk is really insightful and it is super interesting to do a deep dive on these old computer/programming topics as the modern concepts were being discovered
    - nchmy 17d ago
      Hah, I wasn't aware of that. I was sort of referring to what seems to be not such a meme that jblow is always introduced like that. It just seems weird, even if true... Yeah Ive been meaning to watch that talk - I love listening to pretty much anything Casey says/does. He's extremely thoughtful and fair.
    - kshallvari 17d ago
      > I believe this is referencing a meme on the primeagen's standup podcast Exactly!
      - frou_dh 17d ago
        [flagged]
        ModernMech 17d ago
        > devfluencer Thank you for bringing a term to a thing that has been bugging me: people who purport to be devs but spend most of their time on podcasts and blogs talking and writing about being devs, rather than just being devs.
        miyoji 17d ago
        Yes, programmers are exactly like everyone else in this way.
        kshallvari 17d ago
        Oh really, just for a funny joke?
  - dist-epoch 17d ago
    No, that would be John Carmack
    - flumpcakes 17d ago
      Death-frightening scion capable of seeing beyond the illusionary world before our eyes John Carmack?
tialaramex 17d ago
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. Measure. If you aren't measuring that's not optimization it's masturbation. Ironically in the process of measuring for a third time yesterday I tripped a bug in Bill's language for which I opened an issue. This is not the goal of measuring three times but merely a happy accident. Along the way Casey discovers (?) that Structured Programming means just what we today call programming†, that software was a lot smaller in the days when 4096 bytes of RAM was a good entry level option and that loads of these famous people from 1970s computer science knew each other. † And knowing about this is one reason the Structured Concurrency people want that everywhere. Very possibly there's a future where it seems silly that people once wrote programs which did not use structured concurrency.
- socalgal2 17d ago
  > Measure. Measure. Measure. The problem is knowing what to measure. There's another saying "When a measure becomes a target, it ceases to be a good measure." As an example from memory, there was a game dev company that celebrated they had maxed out the cores on the PS3. That didn't mean anything though, anyone can max out the cores by filing them with bad code. But hey, their "measurement" told them they had maxed out the machine
  - tialaramex 17d ago
    > The problem is knowing what to measure. This can be a problem, but much less so because so often we're doing "easy mode" where we don't need a proxy. The "it ceases to be a good measure" is because you're measuring a proxy. You wanted to deliver happiness, you measured wealth because it was easier to measure but seemed correlated and now you've got rich miserable people, oops. But software engineers can often measure the actual thing they want to improve directly, not a proxy and so it cannot cease to be a good measure.
cuechan 17d ago
He is just legendary when it comes to game programming
- socalgal2 17d ago
  What games has he shipped?
  - dundarious 17d ago
    He did middleware at RAD, home of a lot of good stuff, and worked directly on at least The Witness
  - moefh 17d ago
    He works in the engine/tool side of things. He worked on some widely used libraries, mainly Bink 2 (video codec) and Granny 3D (3D animation) used in a ton of shipped games.
  - singleshot_ 17d ago
    Very interesting that the Christmas Disk still has not been released.
  - sirwhinesalot 17d ago
    The legendary games programmer thing is a meme. Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed. What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professional success to a large extent. He did work on the video games Dungeon Siege and The Witness afaik, but that's not what he is known for. He also made one of the fastest terminal emulators (refterm), purely out of spite, to show Microsoft they were full of shit in their answer to an issue he posted to the Windows Terminal github. This directly led to performance improvements in Windows Terminal.
    - inigyou 17d ago
mberning 17d ago
Will have to give this a watch after the kids go to bed. I like a lot of Casey’s views even if I don’t agree with them.
torginus 17d ago
Personally I'm quite sure this is super interesting, but I don't really have 3 hours to listen to this, even 1.5h at 2x speed is too much. I would very much prefer something written down, so I could absorb this at my own pace. I know, gift horse, but still.
- knollimar 17d ago
  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 elsewhere.
  - abainbridge 17d ago
    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.
    - mrkeen 17d ago
      Hard to tell if sarcastic, but anyway. I think the GOTOers just died out. Some day null, statements (rather than expressions) and side-effects will have always been wrong.
      - knollimar 17d ago
        No, they're not sarcastic. It was an interesting point; if an idea succeeds well enough people just do it and make it "common sense". It's a point in the talk.
      - tialaramex 17d ago
        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 unbothered by context. Want to go from the middle of this code about employee payroll processing to mid-way through initializing a weather simulation? No problem. Well. No problem for the machine, for a human programmer it's a complete nightmare. Actually that's putting it mildly, nightmares have more structure. You cannot do anything like that with for example C's goto. You compiler can, and in a few cases (that's what the discussion about the tail-call optimisation is about for example) it will, but the program you wrote doesn't do this and so you don't have to try to keep the whole program in your head. So in that sense GOTO died out with, maybe BASICs? I think the BASICs tend to have that wolf nature GOTO feature, but nothing modern has it.
jeffrallen 17d ago
It's premature optimization, according to the video description.
Almondsetat 17d ago
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
- JamesSwift 17d ago
  Ehh I love Casey and have learned a ton by watching how he thinks about things in his handmade hero series, but he is fairly narrow minded in his views of dev. Not that theres anything wrong with that, for the kinds of dev he does his approach is very good. But its not generalizable.
  - OtomotO 17d ago
    Absolutely. Like I agree with most everything he says and I like to optimise my own software, but for my day to day jobs and contracts it's simply not feasible. That level of performance and rigor is not what is demanded nor paid or appreciated. E.g. in Enterprise circles it's still OOP from top to bottom. Mixed with a tad more functional style due to varying adoption of that paradigm in the languages used by enterprise. But low level optimizations are not interesting to these customers at all, even though they could help them with some problems.
    - hirvi74 17d ago
      > not what is demanded nor paid or appreciated. I suppose it is a matter of what one works on, but that has been consistent in my career. I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.
      - yoyohello13 17d ago
        It’s not a coincidence that Casey and other high profile performance minded people are in game dev. Thats a field where performance is important (or at least a consideration). In web dev or regular enterprise app dev it’s simply not a consideration that needs to be made most of the time.
perkinsResearch 17d ago
Legend
dkersten 17d ago
I enjoyed this talk. It’s long, but it’s interesting and goes into a lot of “lost” history.
FacelessJim 17d ago
Terrific 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 library, but it’s there. Instead he focuses only on “program size”. Knuth samples where very small FORTRAN programs (compared to today’s standards). Today’s program are bigger but the fundamental number crunching primitive of “let’s compute stuff in a loop” remains. It’s just buried under a pile of extra cruft (data loading, parallelism, dispatching etc). Now we just deal with a lot more programs that are of a whole different class compared to what they where doing with computers in the 70s. We have much more I/O involved. And hot loops don’t like being I/O bound.
- dundarious 17d ago
  He has addressed the "hotspot" notion in the past, one example being part of https://youtu.be/x2EOOJg8FkA https://youtu.be/x2EOOJg8FkA
  - dundarious 17d ago
    Realizing I didn't quite answer your question about types of programs then and now. In the Q&A, they do discuss what types of (Fortran only) programs were measured in the study, and there is some speculation, but unfortunately the documentary record wasn't particularly solid.
- collinstevens 17d ago
  > I found it weird he didn’t mention the difference of types of programs of then vs now. iirc, in the talk casey in fact does goes on about how he tried to find examples, but couldn't. in the q&a, he was also asked about this further.
- Pannoniae 17d ago
  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 / mental justification of why your program is slow instead of an honest reason for so.
Panzerschrek 17d ago
It's a common situation for many quotes of such kind. Taken out of context they loose or completely change their initial meaning.
jdw64 17d ago
Do not guess. Measure, but only measure the bottlenecks that threaten the business
fantasizr 17d ago
I took notice when he breaks down the ethics of gen ai as it pertains to online theft, that AI broke the natural order of putting content online where you'd trade exposure for use https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244 https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244
register 17d ago
What is the thesis of his talk? Is it worth viewing?
- Tuna-Fish 17d ago
  He tracks down where the statement "Premature optimization is the root of all evil" actually comes from, and whether the assumptions set out in the text where it was published still hold. It doesn't really contain anything new or earthshattering, but if you find diving into the history of programming as a discipline interesting, it might be for you. I would recommend it to anyone who liked the rambling style of "The big OOPs", but imo that one was better. I still liked it.
ex-aws-dude 17d ago
What 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 to working in games that they take it for granted that the business incentive for performance exists As someone who has worked in both AAA games and big tech it just comes across as a bit naive to me
- softwaredoug 17d ago
  I think there could be a version of our industry with people doing better work. And it’s worthwhile to study why we don’t have that industry. Yes it’s incentives - but why these incentives exist and not others is an interesting question to study. In the 2010s we pushed everyone to learn how to code and maybe lost some of our higher standards. Maybe we’re doing that now with AI? Maybe broader social and economic incentives have had a lot of short term thinking of late? It’s hard to organize society or a company to go in one direction very long before incentives completely change everything. Who knows, maybe that’s a feature, not a bug. It’s worth asking though why we have this software industry and not another one. I’m not convinced it’s for legitimate reasons.
- stereolambda 17d ago
  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.
- 17d ago
fizlebit 17d ago
I 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?
thedevbirb 16d ago
[dead]

326 points by surprisetalk 20d ago

kshallvari 17d ago

THE LEGENDARY GAME PROGRAMMER

nchmy 17d ago
Isn't that Jonathan blow? (to be clear, I'm a big fan of Casey)
- dgellow 17d ago
  They are both legendary game programmers
  - inigyou 17d ago
    Are they? Casey programmed the walk monster for Jon's game, a brute force tester to make sure you could always walk both ways and never get stuck, instead of building the walking system using a nav mesh. There was one place you could walk where you weren't supposed to, despite the walk monster, that would have been obvious if it was a nav mesh.
    - dgellow 17d ago
      He’s known for his Handmade hero series (unfortunately archived now) where he developed his game over 500+ episodes: https://hero.handmade.network/ 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
      - bena 17d ago
        660+ and the game was never finished
        inigyou 17d ago
        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.
        tialaramex 17d ago
        Sure, but the biggest reason to direct anybody to these videos is that they should actually make that video game they want to make, not just think about it - and so the fact that Handmade Hero just trails off and doesn't end up producing a finished video game is a problem. The craftsmanship is dubious. I think it's a problem that people assume Casey knows what he's doing when so often he's like "We're doing it live" and Casey's hand coded solution is pretty bad whereas the thing which came in the box is very good. Casey understands Casey's version, and that's an upside if you are Casey but you are not. If the result was a finished game then hey, whatever, the game was finished and that matters. But that part didn't happen either, so then it's just like watching Tsoding or something.
        ahaferburg 17d ago
        At some point I stopped caring about Handmade Hero because he just never got out of the global illumination rabbit hole. He should have followed that as a side quest, behind a feature flag. Maybe one week for progress on the game, one week for rendering experiments. He didn't seem to make much progress, and it just fizzled out as he ran out of steam. Finishing should have been a bit higher on the priority list. It was just not setting a good example from a project or self management perspective.
        guitarlimeo 17d ago
        Well Billy Basso was hugely inspired by the Handmade Hero series and went on to make the critically acclaimed Animal Well because of it. That's enough of a win for that series in my eyes.
        andersonpico 17d ago
    - 3eb7988a1663 17d ago
      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?
      - tialaramex 17d ago
        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.
        dgellow 17d ago
        I think you’re both saying the same thing
        3eb7988a1663 17d ago
        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.
        jodrellblank 8d ago
        > "if walk monster manually trolls the map" Casey Muratori has a 50 minute video on "Killing the Walk Monster" which is about how they started looking for glitchy game geometry by pretending to be a player walking around, then by a flood-fill ("walk monster") probing for barriers, then the video is explaining how they designed something "exponentially faster" (both demonstrated starting at time 38:33). The better version was realtime enough that level designers could use its overlays interactively while working on the level, and during test playthroughs. He describes it as "exponentially faster". It doesn't seem like the earlier poster calling it "brute force" is a reasonable description. https://www.youtube.com/watch?v=YE8MVNMzpbo https://www.youtube.com/watch?v=YE8MVNMzpbo And the place the player can walk but shouldn't be able to (off the boat), is not a fault in the walk system, as explained in that video near the end, it's a place where level designers made a mistake.
- arnorhs 17d ago
  I believe this is referencing a meme on the primeagen's standup podcast, where Casey is referred to as legendary while he feels undeserving of this title. Titles aside, his talk is really insightful and it is super interesting to do a deep dive on these old computer/programming topics as the modern concepts were being discovered
  - nchmy 17d ago
    Hah, I wasn't aware of that. I was sort of referring to what seems to be not such a meme that jblow is always introduced like that. It just seems weird, even if true... Yeah Ive been meaning to watch that talk - I love listening to pretty much anything Casey says/does. He's extremely thoughtful and fair.
  - kshallvari 17d ago
    > I believe this is referencing a meme on the primeagen's standup podcast Exactly!
    - frou_dh 17d ago
      [flagged]
      - ModernMech 17d ago
        > devfluencer Thank you for bringing a term to a thing that has been bugging me: people who purport to be devs but spend most of their time on podcasts and blogs talking and writing about being devs, rather than just being devs.
      - miyoji 17d ago
        Yes, programmers are exactly like everyone else in this way.
      - kshallvari 17d ago
        Oh really, just for a funny joke?
- dist-epoch 17d ago
  No, that would be John Carmack
  - flumpcakes 17d ago
    Death-frightening scion capable of seeing beyond the illusionary world before our eyes John Carmack?

tialaramex 17d ago

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. Measure. If you aren't measuring that's not optimization it's masturbation. Ironically in the process of measuring for a third time yesterday I tripped a bug in Bill's language for which I opened an issue. This is not the goal of measuring three times but merely a happy accident. Along the way Casey discovers (?) that Structured Programming means just what we today call programming†, that software was a lot smaller in the days when 4096 bytes of RAM was a good entry level option and that loads of these famous people from 1970s computer science knew each other. † And knowing about this is one reason the Structured Concurrency people want that everywhere. Very possibly there's a future where it seems silly that people once wrote programs which did not use structured concurrency.

socalgal2 17d ago
> Measure. Measure. Measure. The problem is knowing what to measure. There's another saying "When a measure becomes a target, it ceases to be a good measure." As an example from memory, there was a game dev company that celebrated they had maxed out the cores on the PS3. That didn't mean anything though, anyone can max out the cores by filing them with bad code. But hey, their "measurement" told them they had maxed out the machine
- tialaramex 17d ago
  > The problem is knowing what to measure. This can be a problem, but much less so because so often we're doing "easy mode" where we don't need a proxy. The "it ceases to be a good measure" is because you're measuring a proxy. You wanted to deliver happiness, you measured wealth because it was easier to measure but seemed correlated and now you've got rich miserable people, oops. But software engineers can often measure the actual thing they want to improve directly, not a proxy and so it cannot cease to be a good measure.

cuechan 17d ago

He is just legendary when it comes to game programming

socalgal2 17d ago
What games has he shipped?
- dundarious 17d ago
  He did middleware at RAD, home of a lot of good stuff, and worked directly on at least The Witness
- moefh 17d ago
  He works in the engine/tool side of things. He worked on some widely used libraries, mainly Bink 2 (video codec) and Granny 3D (3D animation) used in a ton of shipped games.
- singleshot_ 17d ago
  Very interesting that the Christmas Disk still has not been released.
- sirwhinesalot 17d ago
  The legendary games programmer thing is a meme. Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed. What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professional success to a large extent. He did work on the video games Dungeon Siege and The Witness afaik, but that's not what he is known for. He also made one of the fastest terminal emulators (refterm), purely out of spite, to show Microsoft they were full of shit in their answer to an issue he posted to the Windows Terminal github. This directly led to performance improvements in Windows Terminal.
  - inigyou 17d ago

mberning 17d ago

Will have to give this a watch after the kids go to bed. I like a lot of Casey’s views even if I don’t agree with them.

torginus 17d ago

Personally I'm quite sure this is super interesting, but I don't really have 3 hours to listen to this, even 1.5h at 2x speed is too much. I would very much prefer something written down, so I could absorb this at my own pace. I know, gift horse, but still.

knollimar 17d ago
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 elsewhere.
- abainbridge 17d ago
  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.
  - mrkeen 17d ago
    Hard to tell if sarcastic, but anyway. I think the GOTOers just died out. Some day null, statements (rather than expressions) and side-effects will have always been wrong.
    - knollimar 17d ago
      No, they're not sarcastic. It was an interesting point; if an idea succeeds well enough people just do it and make it "common sense". It's a point in the talk.
    - tialaramex 17d ago
      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 unbothered by context. Want to go from the middle of this code about employee payroll processing to mid-way through initializing a weather simulation? No problem. Well. No problem for the machine, for a human programmer it's a complete nightmare. Actually that's putting it mildly, nightmares have more structure. You cannot do anything like that with for example C's goto. You compiler can, and in a few cases (that's what the discussion about the tail-call optimisation is about for example) it will, but the program you wrote doesn't do this and so you don't have to try to keep the whole program in your head. So in that sense GOTO died out with, maybe BASICs? I think the BASICs tend to have that wolf nature GOTO feature, but nothing modern has it.

jeffrallen 17d ago

It's premature optimization, according to the video description.

Almondsetat 17d ago

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

JamesSwift 17d ago
Ehh I love Casey and have learned a ton by watching how he thinks about things in his handmade hero series, but he is fairly narrow minded in his views of dev. Not that theres anything wrong with that, for the kinds of dev he does his approach is very good. But its not generalizable.
- OtomotO 17d ago
  Absolutely. Like I agree with most everything he says and I like to optimise my own software, but for my day to day jobs and contracts it's simply not feasible. That level of performance and rigor is not what is demanded nor paid or appreciated. E.g. in Enterprise circles it's still OOP from top to bottom. Mixed with a tad more functional style due to varying adoption of that paradigm in the languages used by enterprise. But low level optimizations are not interesting to these customers at all, even though they could help them with some problems.
  - hirvi74 17d ago
    > not what is demanded nor paid or appreciated. I suppose it is a matter of what one works on, but that has been consistent in my career. I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.
    - yoyohello13 17d ago
      It’s not a coincidence that Casey and other high profile performance minded people are in game dev. Thats a field where performance is important (or at least a consideration). In web dev or regular enterprise app dev it’s simply not a consideration that needs to be made most of the time.

perkinsResearch 17d ago

Legend

dkersten 17d ago

I enjoyed this talk. It’s long, but it’s interesting and goes into a lot of “lost” history.

FacelessJim 17d ago

Terrific 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 library, but it’s there. Instead he focuses only on “program size”. Knuth samples where very small FORTRAN programs (compared to today’s standards). Today’s program are bigger but the fundamental number crunching primitive of “let’s compute stuff in a loop” remains. It’s just buried under a pile of extra cruft (data loading, parallelism, dispatching etc). Now we just deal with a lot more programs that are of a whole different class compared to what they where doing with computers in the 70s. We have much more I/O involved. And hot loops don’t like being I/O bound.

dundarious 17d ago
He has addressed the "hotspot" notion in the past, one example being part of https://youtu.be/x2EOOJg8FkA https://youtu.be/x2EOOJg8FkA
- dundarious 17d ago
  Realizing I didn't quite answer your question about types of programs then and now. In the Q&A, they do discuss what types of (Fortran only) programs were measured in the study, and there is some speculation, but unfortunately the documentary record wasn't particularly solid.
collinstevens 17d ago
> I found it weird he didn’t mention the difference of types of programs of then vs now. iirc, in the talk casey in fact does goes on about how he tried to find examples, but couldn't. in the q&a, he was also asked about this further.
Pannoniae 17d ago
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 / mental justification of why your program is slow instead of an honest reason for so.

Panzerschrek 17d ago

It's a common situation for many quotes of such kind. Taken out of context they loose or completely change their initial meaning.

jdw64 17d ago

Do not guess. Measure, but only measure the bottlenecks that threaten the business

fantasizr 17d ago

I took notice when he breaks down the ethics of gen ai as it pertains to online theft, that AI broke the natural order of putting content online where you'd trade exposure for use https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244 https://youtu.be/bjO-s4rNPlY?si=uAtBTb6V_Sw1puBU&t=2244

What is the thesis of his talk? Is it worth viewing?

Tuna-Fish 17d ago
He tracks down where the statement "Premature optimization is the root of all evil" actually comes from, and whether the assumptions set out in the text where it was published still hold. It doesn't really contain anything new or earthshattering, but if you find diving into the history of programming as a discipline interesting, it might be for you. I would recommend it to anyone who liked the rambling style of "The big OOPs", but imo that one was better. I still liked it.

ex-aws-dude 17d ago

What 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 to working in games that they take it for granted that the business incentive for performance exists As someone who has worked in both AAA games and big tech it just comes across as a bit naive to me

softwaredoug 17d ago
I think there could be a version of our industry with people doing better work. And it’s worthwhile to study why we don’t have that industry. Yes it’s incentives - but why these incentives exist and not others is an interesting question to study. In the 2010s we pushed everyone to learn how to code and maybe lost some of our higher standards. Maybe we’re doing that now with AI? Maybe broader social and economic incentives have had a lot of short term thinking of late? It’s hard to organize society or a company to go in one direction very long before incentives completely change everything. Who knows, maybe that’s a feature, not a bug. It’s worth asking though why we have this software industry and not another one. I’m not convinced it’s for legitimate reasons.
stereolambda 17d ago
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.
17d ago

fizlebit 17d ago

I 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?

thedevbirb 16d ago

[dead]