3 ms·

>Kay's ideas about "messaging" were never communicated well. Yeah, he just started one of the most popular programming styles that is still taught in universit

>Kay's ideas about "messaging" were never communicated well. Yeah, he just started one of the most popular programming styles that is still taught in universities (even if a different version than the one he envisioned) > He seemed to be arguing for a pure imperative style. You send a message to make something happen. This is the opposite extreme from pure functional programming. A style of programming where everything is an imperative statement with no return value might be possible. Agreed, OOP is orthogonally opposite of pure functional programming. Objects have state. Big revelation. >Functional programming makes things local. Pure imperative programming makes things global. This is hard on human programmers. It takes more short-term memory than most humans have to work in pure imperative mode. Imperative programming =/= OOP, are you even aware of OOP and its relation with Alan Kay? Not sure if I should argue anything here, but in summary, OOP doesn't make things global, it precisely limits the knowledge and effect of objects, its originally inspired by cells, which have cell walls and communicate via specific hormones with other cells. Have you ever used a language with private modifiers to variables or something? On simulation, it's worth noting that OOP was developed when the prevailing architecture was a full-local monolith, with the advent of the internet the prevailing architecture was client-server and microservices. In this context OOP becomes the default, and objects no longer need to be simulated, but are natural objects in the world. A GUI is an object nowadays, some HTML running in a browser, and the server is another object, a server running in AWS. > Kay thought of it as a central organizing concept for computing. That's not where the field went. Absolutely the opposite, the only central organizing concept would be the scheduler/simulator I guess? Since machines were usually single processor machines, there was a central abstraction that allowed independent objects to exist, processes for example are designed to be separate and independent, you can separate them across machines or run them in the same machine without much difference, you wouldn't argue that processes are a form of centralized computing? It's a feature designed precisely for the opposite, independence of compute and memory fractions. The fact that many independent processes/objects run in the same computer and that it somehow needs to allocate compute resources between them, is not a central architecture. Are hypervisors and Virtual Machines a centralized computing architecture? That's just ridiculous. It's quite the opposite. There's a federated layer in VMs, in processes and in Object Oriented Languages yes, but it is completely practical removable and splittable into separate physical layers due to the nature of its design.

Animats 2y ago
Objects, as implemented today, are mostly a scoping mechanism to package data with functions that work on it. But that wasn't entirely what Kay was proposing. He wanted objects to "send messages" to each other, as if they were nodes in a distributed system. Hence the "message" terminology Discrete-event simulators really work that way, but not much else does. OOP is two way - class functions return values. (I got this early view when I had a tour of PARC in 1975, and Kay explained his thinking.)
- kragen 2y ago
  to a significant extent you can do #doesNotUnderstand: in python, ruby, clos, or spidermonkey javascript†, which was the extent to which that kind of completely dynamic message sending was implemented in smalltalk-76. (smalltalk-72 was more radical.) you can think of the synchronous implementation of message sends as dynamically-dispatched subroutine calls (already more or less present in smalltalk-72) either as a helpful convenience or as a fatal compromise of kay's pure actors-like model it's true that not many systems really depart from that tradition and go fully asynchronous: 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. and for hysterical raisins their asynchronous tasks aren't called 'objects'. but i don't think it's really true that that style of programming is entirely limited to discrete event simulators! ______ † __getattribute__ or __getattr__, method_missing, no-applicable-method, and __noSuchMethod__ respectively
  - TZubiri 2y ago
    "not many systems" "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.

Animats 2y ago

Objects, as implemented today, are mostly a scoping mechanism to package data with functions that work on it. But that wasn't entirely what Kay was proposing. He wanted objects to "send messages" to each other, as if they were nodes in a distributed system. Hence the "message" terminology Discrete-event simulators really work that way, but not much else does. OOP is two way - class functions return values. (I got this early view when I had a tour of PARC in 1975, and Kay explained his thinking.)

kragen 2y ago
to a significant extent you can do #doesNotUnderstand: in python, ruby, clos, or spidermonkey javascript†, which was the extent to which that kind of completely dynamic message sending was implemented in smalltalk-76. (smalltalk-72 was more radical.) you can think of the synchronous implementation of message sends as dynamically-dispatched subroutine calls (already more or less present in smalltalk-72) either as a helpful convenience or as a fatal compromise of kay's pure actors-like model it's true that not many systems really depart from that tradition and go fully asynchronous: 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. and for hysterical raisins their asynchronous tasks aren't called 'objects'. but i don't think it's really true that that style of programming is entirely limited to discrete event simulators! ______ † __getattribute__ or __getattr__, method_missing, no-applicable-method, and __noSuchMethod__ respectively
- TZubiri 2y ago
  "not many systems" "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.