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

171–180 of 229 posts

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

#171

Post by Jach »

nextaccountic wrote: post #161
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

The trouble is, his knowledge covers just a slice of it. He won't talk about stuff like functional programming for instance

This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally.

While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say (the root of all evil phrase being one of them), he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and if possible also talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.

Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) It's just one small part of history. A "complete" history as the top comment suggests would be better as a multi-author endeavor, would probably need many books, and that's if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.

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

#172

Post by ButlerianJihad »

danpalmer wrote: post #170
ex-aws-dude wrote: post #132

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…

Setting aside incentives – because I think that's very fair to push back on, we should strive for better craft... I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.…

Heh heh heh. In actuality, Jon Blow has plenty of experience with distributed and multi-user systems. I worked closely with him while we were developing TinyMUCK 2.x, and the MUF programming language, a stack-based, simplified Forth.

In fact, Jon played a crucial role in the invention of the first MUF worm. We had just finished an extension to MUF that permitted triggering programs wherever a text string was expected. This gave a great flexibility and functionality to run MUF programs passively, by third parties, all kinds of new ways.

Unfortunately this also gave rise to a "worm" type of MUF that replicated itself whenever it was triggered passively. We went a little crazy when this was discovered, but it was all part and parcel of a multi-user game system, where there were permissions to consider, and multiple read/write/execute access to objects that should be owned by their respective player characters.

Jon Blow also inspired a lot of my exploits as I tested other systems of MUD programmability. In that time, TinyMUSH was also experimenting with a language that was more akin to scripting, and boy was it vulnerable. TinyMOO was also coming out, with a rather revolutionary programming paradigm. So in the mid-1990s, just in the insular TinyMU* world, there were at least 3 branches of programmable MUDs being actively developed.

Hopefully Jon could recall my greatest contribution to the corpus of early MUF programs. On Atlantis MUCK, I programmed a simulation of Conway's Game of Life. Of course, there was no animation possible and there was no multithreaded execution possible, either. So my program was given a starting board of Life, and then computed each frame in sequence, output it into the text stream of the game, and terminated after N iterations. Meanwhile, the entire game server locked up, because it could only run one MUF program at a time. Everyone else's commands and input would be held until my MUF program finished running.

This was a real issue, of course, and Jon and I worked to mitigate the problems caused. I think, ultimately, we just limited the number of iterations or the number of instructions that could be executed by any one MUF program at a time.

But Jon and I collaborated on a tutorial for player-programmers, and he helped us find and extinguish many bugs. And these were very complex systems, with 64 or even 256 simultaneous players.

Perhaps Jon has forgotten some of those lessons, but perhaps not.

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

#173

Post by josephg »

nextaccountic wrote: post #161
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

The trouble is, his knowledge covers just a slice of it. He won't talk about stuff like functional programming for instance

Yeah. Casey is just some guy who’s good at software and YouTube. I’ve worked with dozens of people at his level technically. But very few with his interest and skill at making videos.

It’s a pity there’s not more people like him. I’ve met some incredibly smart people in the FP world. I wish more of them made approachable YouTube videos explaining what they know. I recently learned about “Safe Haskell” which, if adapted to rust and other languages, could solve a lot of the security problems with npm and cargo. But nobody knows about it! We need FP Casey.

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

#174

Post by josephg »

Jach wrote: post #171
nextaccountic wrote: post #161

Earlier quoted context omitted.

The trouble is, his knowledge covers just a slice of it. He won't talk about stuff like functional programming for instance

This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally. While I suspect he could do research, he also just isn't…

If you know this stuff, please make videos / talks yourself going through it. Casey doesn’t have the background for a lot of this. He’s doing great as a C++ dev but as you say, he’s just one guy with one perspective.

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

#175

Post by gessha »

JavierFlores09 wrote: post #73
gessha wrote: post #62

Earlier quoted context omitted.

It’s on YouTube, pull the transcript and format it with an LLM. If there’s no transcript, there’s Whisper. All of this can be done with local models too.

Audio transcription is nowhere near the same as a properly written piece of text. Videos are simply a different format, and thus a lot of the communication is held by the fact that there's visual cues to go by. If one were to write an article about the same, you'd use much denser language as well as references/links around the topic. Maybe even restructure the whole thing to communicate it better through text. It is…

Yes but in the absence of a blog version, what are you going to do?

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

#176

Post by Jach »

hirvi74 wrote: post #149
AnimalMuppet wrote: post #104

Earlier quoted context omitted.

> 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 coincidenta…

One of the principles of structured programming is that you organize your code into functions, and that they have single points of entry, and single points of exit. We still have a lot of multiple points of exit in functions these days, but the reasons for them usually fall into either those of clarity (less nesting/branching) or performance by skipping unnecessary work, and the consequences of them are less dire in modern high level languages because such languages have GC (no fear of skipping a memory cleanup step) and features like try..finally to ensure code closing file handlers or logging or whatever is executed at the end. But we have largely eliminated multiple points of entry from most code. The main remnant I can think of is in the form of coroutines, though they are structured and limited enough (like modern gotos) and have well defined lifecycles that it's more forgivable.

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

#177

Post by Jach »

fwlr wrote: post #167
andersonpico wrote: post #156

Earlier quoted context omitted.

> He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same project file and code files. this shouldn't be right, wtf

Yes, it really shouldn’t, and so Casey goes to great and careful lengths to fully evidence these results. This is a nuance that’s easy to miss in evangelizing “Casey Muratori content” to others. It’s easy to gloss “abjectly unacceptable performance” as “bad performance”.

And people still come out of the woodwork with a parade of excuses, and sometimes he addresses those too. But it's no wonder that he gets a bit brisk or blunt with people, and turns off others who haven't been following along.

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

#178

Post by dundarious »

dundarious wrote: post #30
FacelessJim wrote: post #22

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 libra…

He has addressed the "hotspot" notion in the past, one example being part of https://youtu.be/x2EOOJg8FkA

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.

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

#179

Post by zbentley »

groundzeros2015 wrote: post #151
zbentley wrote: post #107

Earlier quoted context omitted.

> If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare This is backwards. I bet that by count, many more programs are written in domains where they're necessarily IO bound than the inverse. Anything that uses the network for its core functionality, anything reliant on a datasource whose aggregate contents are O(memory)+ size, or anything reliant on sl…

Bottleneck is a misleading word here. Yes the network is slow. But you can still save 200ms in response time by working on your CPU.

Neither I nor GP used that word.

You're not wrong in that there are some programs that could be doing more work in CPU/memory while waiting for IO, but those, too, are dwarfed by the number of programs that can't really do anything meaningful until IO completes. Anything that RPCs or IPCs data is generally going to be waiting for a complete RPC IO to finish before doing compute (and even the most granular RPC protocols tend to communicate in pretty big, slow chunks to maximize throughput). Lots of software waiting on local hardware (e.g. storage) is similarly doing IOs in pretty big pieces--maybe page-sized, or disk-block-sized, or file-sized--and can't do much meaningful CPU work until that's done. In embedded, it often behooves programs to get as much IO-sourced data read or written as is possible with available resources before switching back to CPU work--doing this increases throughput on slow hardware, and can also improve power efficiency.

Put another way: modelling IO as a stream with something like io_uring won't save the end user much latency if the completions inside the ring wait for slow, batched IO, or if application code needs to see completed transactions before proceeding.

Latency, throughput, power, hardware cost--those often trade off, and there's no free lunch.

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

#180

Post by Jach »

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

Pretty much any book or long paper that decides to take a historical turn is going to be at least as good if not better than these talks. There are a lot of historical resources out there that go into different parts of "computing history" more generally. I don't know what would meet your criteria for computer science or software engineering more narrowly. To me they are all very interconnected. I couldn't say whether it'd be more important to have a nice presentation that includes Babbage and his machines vs. a neat presentation that covers Codd's work going directly into Chamberlin and Boyce's work on System R. A historical presentation has to decide what it includes and excludes. In recent times I've enjoyed Fabien Sanglard and his work on the histories of Wolfenstein 3D, Doom, the hardware environments behind them (development and deployment), and the CP-System. Lots of "lost" technical knowledge in them. Of course the earlier and higher level Masters of Doom book contains a lot of neat history as well, though less technical. The HOPL (History of Programming Language) papers are always insightful and contain a lot more "plain" computer science, though of course with a focus on programming language things. Richard Gabriel could write a lot more of history than he already has; here's one of his papers that (among other things) details a history of mixins in object oriented languages, and how they were "rediscovered" poorly in a way that obscured their actual historical nature, demonstrating an idea of incommensurability. https://dreamsongs.com/Files/Incommensurability.pdf

I should also add that even interviews are valuable. Coders at Work is fantastic at that and drawing out technical opinions and reasoning; notably the subjects interviewed don't all agree and have sometimes drastically different work styles and preferences. (And also adding from another comment, Turing Award Lectures are great history, and Uncle Bob even has a history book out now on influential programmers.)

Post reply on HN