A critique of object-oriented programming argues that its appeal often comes from language limits, corporate team structure, and visible scaffolding rather than necessity. It allows that OO fits some domains, but not every program.
Object-oriented programming should not pervade every program
Programs need new types without forcing every solution into type definitions
2 / 11
Five reasons drive object-oriented programming's appeal, and three and a half are bad
3 / 11
Object-oriented programming fits big companies by constraining large, changing teams of mediocre programmers
Big-company code accepts bloat and duplication because discipline matters more than elegance there
4 / 11
Object-oriented programming can make simple tasks look like substantial work through extra scaffolding
A Lisp hacker might push a symbol onto a list where object-oriented code needs whole class files
5 / 11
Object-oriented programming is exciting in statically typed languages without lexical closures or macros
In those languages, it partly works around missing features, as in Greenspun's Tenth Rule
6 / 11
Object-oriented abstractions map well to some domains, like simulations and CAD systems
7 / 11
Sub-concepts like overloading are not inherently tied to classes and can be offered separately
8 / 11
Common Lisp has a powerful object system, but it was never needed here, not even once
Hash tables full of closures handled problems that wimpier languages would require object-oriented techniques for
9 / 11
Designing a language from personal experience is risky, but adding features never needed is riskier