I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messag…
Alan Kay on the misunderstanding of OOP (1998)
161–170 of 212 posts
Re: Alan Kay on the misunderstanding of OOP (1998)
#162Earlier quoted context omitted.
What about e.g. HTTP? The dynamics of server to server communication are all about message passing (REST is just a message conveying state, if you ignore the other rules). Look at things like Erlang and Elixir processes. Akka and the actor model. Map/Reduce to a certain extent. These are all founded on the idea of giving a task out with enough information that the worker can reasonably go and work on the task without…
HTTP is closer to RPC. You always know the address of the routine to call, so it's not actually a message (except in HATEOAS, in which you first need to learn the next address from last API call). Closest analogy is the message queue (e.g. ESB) like Active MQ or Rabbit MQ (and the whole JMS tech), in which you do actually send a message and infrastructure does actually figure out who will receive and process it.
Re: Alan Kay on the misunderstanding of OOP (1998)
#163I'm thinking the closest mainstream thing to real messages is probably event handling. Events are nearly always represented as objects of some sort (rather than something simpler like a function call) and event routing is the heart of any UI framework. So maybe the question is whether we should be using events (and streams of events) more? But this doesn't seem like a neglected area - publish/subscribe is pretty comm…
The issue that languages have, is that the syntax obscures this fact instead of highlighting it. There are many different ways of sending a message between objects, and none of them are labeled as such. But essentially, there are just two different models that matter: synchronous send + receive (receive the replied message, the method's return value, before moving on), and asynchronous send + receive (where the receive remembers the context of what was sent that is being replied to). A really simple OO language would just implement those two operations between objects, and would need nothing else.
Re: Alan Kay on the misunderstanding of OOP (1998)
#164Re: Alan Kay on the misunderstanding of OOP (1998)
#165I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messag…
I think he's referring to primitive GET, PUT, POST, DELETE message passing verbs that enable more complex and abstract compositions.
Re: Alan Kay on the misunderstanding of OOP (1998)
#166Earlier quoted context omitted.
I think he's referring to primitive GET, PUT, POST, DELETE message passing verbs that enable more complex and abstract compositions.
HTTP != internet
The spirit of his point, though, appears to be creating decoupled systems from simple message passing protocols.
Re: Alan Kay on the misunderstanding of OOP (1998)
#167Earlier quoted context omitted.
> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.
Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 t…
Re: Alan Kay on the misunderstanding of OOP (1998)
#168I'd love clarification on a few points, from anyone who understands everything Alan says here: Think of the internet -- to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard Is he referring here to alternative protocols from http, or to the fact that behind the single http protocol are servers written in myriad languages and styles? If you focus on just messag…
https://news.ycombinator.com/item?id=11960130
One interesting point from a talk of his - the internet has never broken or been unavailable since they turned it on, even though it has gone through about 3 successive generations of hardware/software.
Re: Alan Kay on the misunderstanding of OOP (1998)
#169I don't really understand this obsession with messages. We're moving away from it. This is not how we program in the 21st century. The last popular language that supported this paradigm (Objective C) is being replaced and will probably be all but gone in just a few years as Swift (not message based) takes it place. Besides, this idea of message passing is really not that useful for modern programming anyway but a lot…
No, message passing doesn’t solve all the problem of parallelism, but it is one of the most powerful and useful tools to have in our toolkit when attacking these problems. I hope it doesn’t dominate as OOP did in the 90s, as many other models such as actor and dataflow still have a lot of room for research and improvement.
Re: Alan Kay on the misunderstanding of OOP (1998)
#170Earlier quoted context omitted.
> If anything I feel the failure of OO languages What failure exactly? OOP has flaws but it has certainly proven to be extremely versatile and adaptable over these past decades since even today, it's still the dominant paradigm to solve modern problems in computing.
Seriously? Have you watched any of the demos Alan references? They were doing things with computers in the 1960s/70s that still haven't reached mainstream use as yet. Computers as used today are still absolutely dumb machines that are little more than super-fast calculators, and in most cases increases the mental burden of their users instead of reducing/augmenting them. Nicholas Negroponte had a great quote in '94 t…