Pitfalls of object oriented programming (2009) [pdf]
Object-oriented programming is probed both as a conceptual model and as a performance trade-off, with many arguing that its emphasis on identity, mutable state, and inheritance often adds complexity without clear benefits over simpler data‑oriented or functional designs. Commenters contrast Alan Kay’s original message-passing vision of objects with how mainstream OO (e.g., Java, C++) is practiced today, highlighting issues like cache-unfriendly object graphs, brittle inheritance hierarchies, and overuse of “everything is an object” thinking. A recurring theme is that no single paradigm suffices: effective systems mix objects, functions, and relational or set-based models, using OO selectively where encapsulated state and polymorphic behavior genuinely help, such as parts of UI code.
What OO “really is”
- Several comments argue Wikipedia’s “data + methods together” definition is misleading.
- One camp says the essence is identity plus mutable state: two objects can be “the same” despite differing fields.
- Another camp stresses message sending + dynamic dispatch: different objects respond differently to the same message; mutability and identity are common but not essential.
- Both views agree memory layout is incidental, not defining.
OO vs other paradigms (identity, sets, relations)
- A recurring theme: OO encourages “intentional identity” (you invent objects/services and push data/behavior into them), which can inflate system complexity.
- In contrast, relational/logic approaches emphasize “extensional identity” (entities are defined by values/tuples; identity emerges from attributes).
- Some note that many developers are so immersed in OO they see it as natural, then awkwardly wrap relational/functional/logic systems inside OO abstractions.
Inheritance, composition, interfaces
- Strong criticism of class inheritance as a primary design tool; composition, interfaces/traits/typeclasses, and delegation are often preferred.
- Others defend inheritance as a powerful, convenient mechanism for extensibility and UI customization, especially when carefully constrained (final classes/methods, clear extension points).
- Debate over whether delegation + generics match inheritance’s expressiveness and ergonomics; agreement that misuse of inheritance easily leads to fragile designs.
OO in GUIs vs backends
- Many find OO fits traditional GUI toolkits well (widgets with state and behavior, hierarchical structure).
- Modern UI frameworks (React, Elm, Compose, SwiftUI) lean toward declarative/functional or reactive styles, though critics argue these still rely on hidden, OO-like state beneath.
- Discussion around React hooks: they feel functional at the surface but break pure FP rules and rely on unusual semantics.
Performance and data-oriented design
- Slides are seen as showing that OO-centric object graphs hurt cache locality and prefetching compared to data-oriented layouts (e.g., arrays/vectors).
- Some generalize: modularity and abstraction often trade off with raw performance; data-oriented design pushes back against that in performance-critical code.
Pragmatism and multi-paradigm use
- Multiple commenters advocate multi-paradigm practice: OO for some parts, FP/relational/logic elsewhere.
- Extreme positions (“everything is an object,” “everything is immutable”) are viewed as counterproductive; the problem should dictate the paradigm.