"only erlang, stackless python, orleans, golang, current ecmascript with promises or web workers, python with asyncio, backends connected together with kafka or rabbitmq or ømq, and a few others."
That's a lot.
I do agree with both that Objects as used in programming languages is a very limited definition and not quite what Kay had in mind.
Kay Objects really exceed even all of the examples quoted above, which are plentiful.
Take a bank for example. Your system may communicate with a bank by using a stripe API or by sending an ACH file to process some transactions. The bank may take the transaction and process it only returning a response, in a somewhat functional request-response fashion. But they might also, by their own volition, send their own messages to the originator, for example a chargeback. They may even send messages unrelated to a specific message, like a request for documentation.
From a technical standpoint, any API system that requires a callback address is probably because they need to send their own messages back, in that case there is a bidirectional channel of communication, and we are talking about Kay objects.
A feature of this interpretation of Kay Objects is that they are not necessarily computer systems, a bank is a juristic entity, its barriers of communication are human as well, they have NDAs and contracts which are not unlike code. They protect their internal state and data, and have specific channels of communication.
> I do agree with both that Objects as used in programming languages is a very limited definition and not quite what Kay had in mind.
Yes. Kay was trying to envision a sort of object oriented nanoservices architecture, decades too early to build it.
Arguably, CORBA came close to that. You create a local proxy object which has a relationship with a non-local object, and talk to the proxy to get the remote object to do things.
Interestingly, there's a modern architecture for distributed multiplayer games which works that way - M2, from Improbable. In-game objects talk to other objects, some of which are on different machines. The overhead and network traffic within the server farm are very high, because there's so much communication going on. It's only cost-effective for special events. But it does work.
"only erlang, stackless python, orleans, golang, current ecmascript with promises or web workers, python with asyncio, backends connected together with kafka or rabbitmq or ømq, and a few others."
That's a lot.
I do agree with both that Objects as used in programming languages is a very limited definition and not quite what Kay had in mind.
Kay Objects really exceed even all of the examples quoted above, which are plentiful.
Take a bank for example. Your system may communicate with a bank by using a stripe API or by sending an ACH file to process some transactions. The bank may take the transaction and process it only returning a response, in a somewhat functional request-response fashion. But they might also, by their own volition, send their own messages to the originator, for example a chargeback. They may even send messages unrelated to a specific message, like a request for documentation.
From a technical standpoint, any API system that requires a callback address is probably because they need to send their own messages back, in that case there is a bidirectional channel of communication, and we are talking about Kay objects.
A feature of this interpretation of Kay Objects is that they are not necessarily computer systems, a bank is a juristic entity, its barriers of communication are human as well, they have NDAs and contracts which are not unlike code. They protect their internal state and data, and have specific channels of communication.