Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Alan Kay on the misunderstanding of OOP (1998)

lists.squeakfoundation.org

Post reply on HN
Print view View original

81–90 of 212 posts

Re: Alan Kay on the misunderstanding of OOP (1998)

#81

Post by kmiroslav »

optforfon wrote: post #48
hackits wrote: post #40

I find it interesting that everyone gets so up-beat about the ideology or philosophical debate about objects sending each object messages, hell even not relying to a message one object send you until a later date. Without even thinking about concurrency, state, and hell even the basics such as cyclic loops within a event based system! Though I keep hearing from Alan and other prominent language designers that we stil…

"For what its worth I consider object's simply as a basic level category of procedures and data tied to a namespace.“ I mean you're just using different words to talk about the same thing. In your terminology inheritance is just extending a namespace and overloading names. How does that discredit or put into question the "mental model of command and control, or structured design concepts" If anything I feel the failu…

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

Re: Alan Kay on the misunderstanding of OOP (1998)

#82

Post by huuu »

gagege wrote: post #77
huuu wrote: post #75

Earlier quoted context omitted.

Does queuing occur when cells communicate?

Sort of. AFAIK, cells basically just send out signals and the nearest available cell with a compatible protein that can "read" the signal picks it up.

Well I asked because lets say queuing does not occur, then you might want to design a system that can send and receive messages in without queue.

Re: Alan Kay on the misunderstanding of OOP (1998)

#83

Post by kmiroslav »

huuu wrote: post #51

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For…

Nothing wrong with looking at nature and trying to get inspiration from it (e.g. neural nets) but ever since we realized that flight was easier to implement with chemical combustion than by flapping wings, we know that just because something works in nature doesn't mean it will be easy to replicate for human use.

Re: Alan Kay on the misunderstanding of OOP (1998)

#84

Post by _asummers »

kmiroslav wrote: post #80

I 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…

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 having to look around for state. Also look at things like FRP and more event driven architectures. While not ThingA sends message to ThingB, ThingA still broadcasts a message, possibly containing the relevant state.

Also almost forgot. Look at the wealth of message queues that exist (RabbitMQ, ActiveMQ, SQS, Kafka, ... the list goes on).

Re: Alan Kay on the misunderstanding of OOP (1998)

#85

Post by aryehof »

digi_owl wrote: post #61
aryehof wrote: post #49

Earlier quoted context omitted.

A "method" is just a programming construct. A message in OOP is sent to an object to tell it to do something itself . In an OO approach, rather than have a Hammer hit a Nail, the Hammer sends a message to a Nail which knows how to be hit .

That makes me wonder though, if i send a message to the same object from two different senders, will the first message affect the outcome of the second? If not then there is plainly little difference between the two, as either action gets a new pristine instance. All in all, this seems to be a whole lot of syntactical hair splitting.

What an object does when it receives a message is hidden, and entirely up to that object.

>>> All in all, this seems to be a whole lot of syntactical hair splitting

Or, simply a case of not understanding.

Re: Alan Kay on the misunderstanding of OOP (1998)

#86

Post by mdpopescu »

dang wrote: post #12
elchief wrote: post #8

How is messaging different than calling a method?

Alan commented on this several times in the AMA he did here a couple days ago: https://news.ycombinator.com/item?id=11957001 https://news.ycombinator.com/item?id=11945986 https://news.ycombinator.com/item?id=11945123

So... it's basically event-driven programming? Objects generate events, and other objects are free to subscribe to them and do something in response (or not)?

I thought of something similar a few years ago, I think it would indeed enable much better decoupling than the current OOP model - instead of object A telling object B "do this" (and thus having to know that object B exists and that it can do "this"), have object A emit an event "I just did this" and let object B, if it's interested, handle that.

There's still the problem of "now B has to know about A", but it can be solved with a common event bus and a series of messages defined in a different library - that way both A and B only know about the common library, they can be completely independent of each other.

I wrote something like this a few years ago - just added it to my GitHub at https://github.com/mdpopescu/public/tree/master/Snake - but I can't say I ever did something "serious" with it. It's one of the things I'd like to actually use in production, like CQRS/ES or Orleans :)

Re: Alan Kay on the misunderstanding of OOP (1998)

#87

Post by ivan_gammel »

_asummers wrote: post #84
kmiroslav wrote: post #80

I 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…

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)

#88

Post by kmiroslav »

_asummers wrote: post #84
kmiroslav wrote: post #80

I 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…

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…

I was talking about programming languages.

Obviously, message passing is alive and well for network protocols.

Re: Alan Kay on the misunderstanding of OOP (1998)

#89

Post by huuu »

kmiroslav wrote: post #83
huuu wrote: post #51

I might be wrong, but I think people like Alan Kay and Christopher Alexander have in common that they: * see that things can be done better (not as in upgrade but best); * have a global idea/feeling of how this could be done; * take a lot of ideas from nature. And somehow I think they have a lot of trouble expressing the 'how'. My take: we should take a good look at nature because this is closest to what we are. For…

Nothing wrong with looking at nature and trying to get inspiration from it (e.g. neural nets) but ever since we realized that flight was easier to implement with chemical combustion than by flapping wings, we know that just because something works in nature doesn't mean it will be easy to replicate for human use.

True. But because as today it's easier to implement doesn't mean we won't have aircraft with flapping wings in the future.

Re: Alan Kay on the misunderstanding of OOP (1998)

#90

Post by pacala »

_asummers wrote: post #84
kmiroslav wrote: post #80

I 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…

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…

Message passing implies one way broadcast. Think GOTO. HTTP is a request / reply protocol, i.e. a function call. Map / Reduce is an implementation device for SQL-like collection-based processing, modern Map / Reduce systems [Google's Flume / Dataflow] offer directly the collection API, using Map / Reduce as an implementation detail. FRP is a device for adding a collection API on top of streams of events. Collection APIs are conceptually function calls over collections [duh].

Just because your compiler uses GOTO / messaging behind the scenes to implement function calls, it doesn't follow that GOTO / messaging is the right API level for designing applications. We know this since 1968.

Post reply on HN