HN Theater @HNTheaterMonth

Some of the ideas that were translated to reality are covered here:

https://www.youtube.com/watch?v=QjJaFG63Hlo

Some of them never got fully translated to reality at Xerox because of various reasons (e.g. memory limitation of hardware at the time). This is worth a read:

http://alumni.media.mit.edu/~mt/thesis/mt-thesis-Contents.ht...

Most Alan Kay's presentations I've seen were worth watching. Tons of great ideas in each. They really improved how I reason about systems.

There is this famous talk from OOPSLA 1997:

https://www.youtube.com/watch?v=oKg1hTOQXoY

If you want to see what "practical" OOP looked like in the 80s, this is a good video:

https://www.youtube.com/watch?v=QjJaFG63Hlo

>Can we extend that logic to classes or interfaces?

This was one of the main ideas behind the original definition of OOP. The original notion of "object" was very similar to our current notion of "service":

https://www.youtube.com/watch?v=QjJaFG63Hlo

Objects received messages, including messages sent over the network. There was not supposed to be a clear distinction between local and remote services - by design. A lot of inter-computer stuff could be/was handled transparently.

I'm watching some OOP videos from mid-eighties right now. Can't shake the feeling that the original notion of OOP was solving the same problems as microservices try to solve today, but with far more elegance and more coherent theoretical framework.

(Example: https://www.youtube.com/watch?v=QjJaFG63Hlo)

⬐ eeZah7Ux

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.

⬐ cookiecaper

>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?

⬐ jjtheblunt

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.

⬐ romaniv

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...

⬐ 0x445442

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.

⬐ barrkel

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.

⬐ neeleshs

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

⬐ romaniv

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.

⬐ ChrisRus

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.