The Big OOPs:
Anatomy of a Thirty-five-year Mistake – BSC 2025
by Casey Muratori
https://www.youtube.com/watch?v=wo84LFzx5nI
I don't watch or attend a lot of conferences and talks these days, probably for the same reasons you shouldn't watch as much tv and believe it all as you used to.
But to me, at least, this is a deep and serious one worth your time in a fundamental way. If you are a programmer who actually cares about code, anyway.
Muratori doesn’t condemn OOP broadly. He specifically critiques the practice of constructing:
“Compile-time hierarchies of encapsulation that match the domain model”
That is, designing class hierarchies that mirror domain entities (Vehicle -> Car) and using inheritance/encapsulation tied directly to those domain shapes.
Why that approach is problematic:
It places modular boundaries in the wrong places, making systems inflexible and brittle as requirements evolve. This model (which Muratori shows to be contradictory, with profuse historical documentation to back his views) overemphasises domain nouns instead of behavioral verbs—leading to rigid designs around entity hierarchies rather than intent or action
When possible, we should first try to write code in a verb‑oriented way –not an object‑oriented way– as naturally people add actions and modify behaviours more frequently than they add new categories and types.
In sum (and this is my own interpretation) what Muratori proposes is... we should introduce the friction of encapsulation and classes not everywhere like dogma, but doing so consciously, in a discerning and methodical way, identifying where we want to place friction in a system's design (making it harder for parts to talk and change one another) and where we need to remove that friction, and to what degree.
What programming we want to make harder, and which programming should absolutely be made easier and streamlined.
What Muratori suggests is not “no encapsulation”, but disciplined encapsulation.
We should introduce friction — like class boundaries or module walls — intentionally, based on where we want parts of the system to resist change or contact.
Ask yourself:
What kinds of programming should be made harder?
And which should be easier?
It's also possible that I didn't really get what the Thief team was trying to do. I expected some more explanation about that towards the end.
Well of course Thief wasn't the point, just a pointer — perhaps to guide further research.
And I don't feel that one single talk would push me to move swiftly and promptly in such a specific direction without mediating a period of further deeper thought.
In any case, it's clear that Muratori is not advocating for any dogmatic or fundamentalist approach to anything, but thinking carefully about the things we are doing, with the tools we are already using today.
A space for Bonfire maintainers and contributors to communicate
