Fifty Shades of OOP

Smalltalk, message passing, and deployment

• Some commenters note that Alan Kay’s vision (Smalltalk, live “image”-based systems, hot code reloading) fits poorly with today’s build–deploy pipelines and short‑lived containers.
• Others counter that message passing and late binding are implementation techniques, orthogonal to the development/deployment model.

Data vs behavior and “anemic” models

• Several people report real‑world OO (especially Java+DB) devolving into “anemic domain models”: classes as mere data carriers plus “service”/“utils” classes with all the logic.
• Opinions differ on whether this is bad design, lack of OO skill, or simply a valid data‑oriented style when combined with immutability and records.

Java, top‑level functions, and frameworks

• Frustration with Java’s lack of top‑level functions leads to “service” classes that are just namespaces.
• Some defend class‑scoped functions as intentional encapsulation; others see them as unnecessary boilerplate since modules/namespaces already organize code.
• Frameworks like Spring/Hibernate are blamed for reinforcing data‑only entities and DI‑driven “god services,” but others stress this is not inherent to the language.

Inheritance, composition, and interfaces

• Strong thread arguing inheritance couples composition and polymorphism unnecessarily; composition + delegation (manual or compiler‑assisted) is preferred.
• Others defend inheritance as the clearest pattern in specific domains (e.g., display object hierarchies), despite alternatives with traits/interfaces and composition.
• Interfaces/protocols are seen as both powerful (plugins, polymorphism) and overused; some note that default methods/mixins are a form of inheritance.

What “counts” as OOP?

• One camp cites an IEEE/Simula‑style definition: encapsulation, inheritance + late binding, and dynamic object creation. By this, C++, Java, and Smalltalk share the same core model.
• Others argue modern languages (Rust, Go, JavaScript prototypes) blur these boundaries: they have encapsulation and polymorphism but often de‑emphasize classes and inheritance.
• Several suggest the interface or message‑based boundary is the real essence of objects; classes, inheritance, and even mutability are optional.

Encapsulation, modules, and alternatives

• Many prefer module‑level encapsulation over per‑object privacy, especially with immutable data.
• Functional styles and languages (F#, Clojure) are mentioned as natural destinations for “OO fatigue,” separating data and functions more cleanly.

History and broader critiques

• Linked talks/papers (e.g., “The Big OOPs”, minimal object models) are referenced to argue that OOP accreted many orthogonal ideas and is often oversold or misunderstood.
• Some claim OOP’s original memory‑management benefits matter less in GC’d, high‑performance runtimes; others emphasize OO’s ongoing value for maintainability and large systems.