> Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint.

Sounds like C.

When was the last time you did OO against a .h file without even needing access to the .c file?

> And so, the process/network boundary naturally became that highest and thickest wall

I've had it both ways. Probably everyone here has. It's difficult to make changes with microservices. You gotta open new routes, and wait for people to start using those routes before you close the old ones. But it's impossible to make changes to a monolith: other teams aren't using your routes, they're using your services and database tables.

> Sounds like C.

Data hiding is just one of the concepts of OOP. Polymorphism is another one.

How that's implemented is another question. You can do OOP in plain C, several libraries kinda did that, like GTK. Other languages tried to support these concepts with less boilerplate, giving rise to classes and such. But OOP is not about language features, it's fundamentally a way of designing software.

It's older than C. But yes, C does module encapsulation.

C is capable enough to program in a way that is basically OOP and without using non-idiomatic code. The C++ object system wasn't created in a vacuum.