OOP is moving between domains, not disappearing. I think this is generally a bad thing.
2025-11-18
Many bytes have been written on the topic of object-oriented programming: what is it? Why is it? Is it good? I’m not sure I have the answers to these questions, but I’ve noticed an interesting trend that I think has flown under the radar: OOP is not disappearing, but rather shifting across domains.
Some quick and completely wrong history
In olden times people used to write programs. Things were easy and simple. Then, a manager, not realizing how much trouble they were getting into, asked two programmers to work on the same program. Bad things happened.
Some bright spark realized that bugs often appear at the intersection of software functionality, and that it might be a sensible idea to do some invasive surgery and separate those functions. interface: At least vaguely specified contract that describes the behavior that two functions can expect from each other.
Other bright sparks jumped into action: What if this separation did not depend on the personal hygiene of programmers – something that should always be questioned for public health reasons – and was instead enforced by language? Components may hide their implementations by default and communicate only through a set of public functions, and the language may reject programs that try to overcome these barriers. How strange.
Nowadays, we have myriad terms for these concepts, and others that have been adopted in an attempt to further the basic idea: encapsulation, inheritance, polymorphism. The goal of all is to attenuate information that can forcibly travel between components. Of course, this basic idea is not unique to OOP, but it is OOP itself that promotes it and flies its coat of arms in the fight with enthusiasm.
programs in the form of classes
Around the same time, some bright spark realized that programmers – a population of people not known for good hygiene – couldn’t produce even the cleanest programs, and maybe it was important not to trust all the little doo-dahs running on your computer. and so the process Limit was born, and operating systems were transformed from friendly personal assistants whose goal was to do the dirty work of programs into childminders whose job primarily consisted of making sure the people within their care didn’t accidentally feed each other snails or paperclips.
At the same time, other bright sparks were discovering that computers could be made to talk to each other, and perhaps this could be useful. Now, programs written by people who didn’t even know each other – let alone trusted each other – could start a conversation.
When trust is lost, society begins to enthusiastically erect the highest and thickest walls possible, no matter what the cost. Software developers are no different. When each program has evolved into a whirlwind of components created by an army of developers who are rarely aware of the inclusions of their software, much less communicate about it, the only reasonable response is maximum disbelief.
And so, the process/network boundary naturally became that tallest and thickest wall of all – just in time for it to replace the aging philosophy of object-oriented programming.
was it worth it?
Our world today is one of microservices, Dockers, clusters, ‘scaling’. The great irony is that the OOP-skepticism you’d hear when whispering about Java to a colleague has been replaced by a monster with exactly the same flaws – but magnified tenfold. OpenAPI schemas replace type-checkers, Docker Compose replaces service factories, Kubernetes replaces event loops. Each call to components generates failure modes, requiring a slow march through (de)serialization libraries, a long trip through the kernel’s scheduler. A TLB cache invalidation here, a socket poll there. Perhaps a secret HTTP request to localhost for desert.
I’m not convinced by the promises of OOP, but I’m even less convinced by the absurdities of what has taken its place.