The Big OOPs: Anatomy of a Thirty-Five Year Mistake

What the “35‑year mistake” is

• Central thesis quoted from the talk: the mistake is treating a compile‑time class hierarchy of encapsulation that matches the domain model as “what OOP is.”
• Commenters clarify: the original vision (Simula, early C++) pushed hierarchies like Shape -> Circle/Triangle as literal encodings of domain taxonomies; this became the default teaching and practice in mainstream C++/Java.
• Critics say this encourages brittle, inflexible large‑scale structure; boundaries should follow computational capabilities or workflows (e.g., ECS, services) rather than “real-world” nouns.

Debate over historical interpretation

• Some argue the presenter accurately shows, via primary sources, that Simula and C++ explicitly promoted domain-aligned hierarchies.
• Others counter that early OOP founders (especially in simulation contexts) used such hierarchies appropriately for that domain, not as a universal rule, and that key figures later acknowledged other valid uses of OO and weaknesses of inheritance.
• There is specific pushback on claims that certain pioneers “soured on” inheritance; commenters quote those same texts as still strongly valuing it, just finding it tricky or under-theorized.
• Disagreement also appears over how representative Smalltalk is in this story and whether the talk overstates its role.

OOP vs ECS, data‑oriented, and other styles

• Many comments enthusiastically endorse ECS and data-oriented design:
  • ECS is explained repeatedly as: entities = IDs; components = data tables; systems = functions over sets of components, akin to an in-memory relational DB.
  • Seen as better for composition, performance, and change (easier to add behaviors than to refactor deep hierarchies).
• Some argue ECS is just another OO pattern or built on OO constructs (traits, protocols, interfaces); others insist ECS is conceptually distinct and more about data layout and queries.
• Several note that early systems (e.g., Sketchpad, later Thief / Looking Glass engines) effectively used ECS-like ideas long before they were named as such.

What counts as “OOP” and what remains after the critique

• One camp: “OOP” as actually practiced = domain taxonomies + inheritance; if you remove that, you’ve removed most of OOP’s distinctive content.
• Another camp: OOP at its core is encapsulation + late binding + dynamic objects; you can use classes, methods, and polymorphism without mirroring the real-world ontology.
• Some commenters go further and question even bundling data with its methods; others defend interfaces/traits as useful contracts even if there’s only one implementation.
• The talk is repeatedly described as anti‑one specific usage of OO, not anti‑OO in general, though some readers use it to reinforce broader anti‑OOP positions.

Language‑specific discussions

• C++/Java:
  • Often cited as the main carriers of the “domain hierarchy” idea; Java especially criticized for forcing everything through classes and for painful corporate legacy (JVM portability vs containers, “jar hell”).
• Python:
  • Debate over “everything is an object” vs being able to write in non‑OO style; distinction drawn between VM semantics and the style of code a programmer can choose.
• Objective‑C, Smalltalk:
  • Briefly mentioned as closer to the Smalltalk branch; some argue protocols/multiple inheritance/traits are ECS‑adjacent; others say that’s conflating ECS with data-oriented design.
• FP & ML‑family:
  • Domain-driven design with sum/product types and “make invalid states unrepresentable” is mentioned as a kind of opposite pole to Casey’s critique, yet still building “compile‑time domain hierarchies” of a different sort.
• Multi‑dispatch and call syntax:
  • Discussion of x.f(y) vs f(x,y), unified call syntax, method chaining, and the “expression problem”; some advocate verb‑oriented APIs and pipes over object‑centric method calls.

Experiential and sociological commentary

• Multiple seasoned developers recount being good debuggers but dismissed when criticizing OOP or inheritance-heavy designs; they describe overengineered Java/C++ systems, brittle taxonomies, and painful testing.
• Several frame OOP’s rise as a generational and consultant-driven fad, similar to waterfall, NoSQL, and certain Agile dogmas: initially useful, then pushed to extremes and defended as “you’re just doing it wrong.”
• Others defend OOP as having been a major improvement in its time, especially for long-running, stateful desktop applications, while conceding today’s stateless, distributed environments favor more functional or data-centric approaches.
• Some worry that similar cycles of hype and backlash will happen around functional programming; they argue tools and paradigms shouldn’t be treated as religions.

Meta: transcripts, AI suspicion, and breadth of evidence

• Several practical tips shared for getting full transcripts of the video (YouTube transcript UI, scripts, external tools, Whisper).
• One highly polished summary comment is suspected of being AI-generated, sparking a side discussion about how LLM style affects trust and how to write more personal, reflective comments.
• One commenter argues the whole debate is skewed by focus on Java/C++ and neglect of ecosystems where OO is perceived to work well (Pascal/Delphi, GUI frameworks, Ruby), suggesting the conversation is overexposed to bad OO and underexposed to success stories.