OO is absolutely the wrong paradigm; at its most elegant OO exceeds at encapsulating one very simple form of automata. But is utterly worthless of modeling hierarchical automata systems with complex dependencies and shared state requirements. Systems modeled using finite state machine models capture the requirements and can be used to generate the runtime. This approach works but suffers from lack of tools and an appalling lack of system design skills in the software community.

Spot on. Objects were meant to be close to microservices, although with the limitation of being implemented in the same language. RPC was meant to allow objects running on different hosts send messages to each other.

That, before OOP turned into the ConfigurationParserSecureProviderCollectorGeneratorFactoryFactoryFactory disaster.

Interestingly, it seems RPC was one of those older ideas that was resurrected and replaced remote message passing when Smalltalk was phased out.

Alan Kay on RPC: "The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Sic transit gloria mundi."

Source: http://mythz.servicestack.net/blog/2013/02/27/the-deep-insig...

>That, before OOP turned into the ConfigurationParserSecureProviderCollectorGeneratorFactoryFactoryFactory disaster.

I think it's naive to design and implement something without the assumption that it will turn into such a disaster. The average skill level of the average person is much lower than anyone reading HN is going to assume.

Instead of releasing pure, useful things that require good judgment to implement, we need to think very lowly of users and make something that is brutally difficult to break, destroy, or corrupt. It will still get broken, destroyed, and corrupted, but we need to build things under the assumption that virtually everyone is going to do it wrong, because they are.

It would be fun to see a development environment designed under that principle, v. the academic "everyone is going to use this judiciously" paradigm that we see governing much of it. Maybe cloud computing and serverless functions is a prototype?

Wasn't a realization of this what Craig Federighi worked on at NeXT? It's been decades since I was a NeXT Registered Developer but I think that existed then, built upon mach ports and a name service daemon the name of which escapes me.

Alan Kay touches on it in some of his talks; the idea that OO is about message sends and that each class should have it's own URL.

That also sounds a lot like DCOM and CORBA. Synchronous rather than async, I know, but making the network transparent is usually not a great idea; networks are so unlike method calls that reliability, performance, throughput, any metric you like will be far, far worse without extreme vigilance.

There is a difference between designing a system where objects always behave similar to network nodes and designing a cludge... I mean, a protocol that allows procedures to be called across a network.

I'm not saying that message-passing is magic and transparently solves all the problems associated with distributed computing, but conceptually it's different from RPC. In fact, it's kind of the opposite of RPC. Keep in mind that Smalltalk 72 was developed in the same environment (Xerox Park labs) that gave us Ethernet and developed large parts of the conceptual framework underpinning our modern networking.

Actor model seems to be a good solution - n/w transparency, ,message passing style, lightweight, and cluster-capable.