Comment by evanmoran | Hacker News Reader

Comment by evanmoran | Hacker News Reader

Parent Full thread

I think messages help better convey three things:

1) that objects are acting like async, independent machines (I picture the erlang actor model, but maybe that’s a stretch.). This makes messages a more natural way to emphasize that these actions can happen across networking or threading boundaries;

2) the message is explicitly not inheritance and therefore doesn’t contain implementation. This means it’s really a messaging contract and only the interface matters!

3) redirecting, storing, or replaying messages are each very powerful concepts that lead to many useful features (networking state, save/load, undo/redo, logging, debugging). Thinking in these terms is much harder to express with functions, so I see this as messages are the _data_ of function calls, and function calls are more the _act_ of calling.

That said, I’d love to hear other’s take on this as well. The differences from functions are subtle and it doesn’t help that we use the same/similar words to mean different things.

In most systems, try to call a method that doesn't exist on something. It will bark at you.

In the types of OO systems Kay discusses, it's up to the receiver to determine whether or not to respond to a message and how to behave if it doesn't "understand" the message. That's how you get maximum polymorphism as well -- for example, all kinds of objects are "cancelable" if they respond to / understand the message #cancel, etc, etc

ok, so truly oriented OO system needs some equivalent of Ruby's method_missing() ? Is that's what you mean?

The structure I'm envisioning here is that every object has a public pass(m) method that takes an input message and has no other public methods. Every message is a legitimate input to pass(m), and every object can call the pass method of any other object. It's up to each object to decide for itself what it will do with any given message that it receives. If an object wants a response to its message it can identify itself in the message and then hopefully the object being passed the message will choose to pass a message back.

This seems exactly analogous to how a collection of webservers interact. They can only communicate with each other by tossing a chunk of bytes around hoping that the target knows what it's supposed to be doing with those bytes.

> and every object can call the pass method of any other object. It's up to each object to decide for itself what it will do with any given message that it receives.

It's a horrible programming model, though. We should be glad this is not how most languages work.

>It's a horrible programming model, though.

Have you ever actually programmed in this model? I wrote a correct RAFT library in ~300 lines of code that are extremely legible using this model.

> It's a horrible programming model, though. We should be glad this is not how most languages work.

This is not only about languages, but also environments. The argument Kay makes is that in order to make very large complex systems that are resilient, you need something like this kind of message passing. And indeed, this is how the Internet works too

The Internet works in hundreds of different ways, message passing, RPC, REST, store and forward, propagation, etc...

It's all made possible because of the protocol which is a kind of message passing. If a node somewhere on the Internet doesn't receive a packet for whatever reason, the whole network doesn't come crashing down.

I'm not sure method_missing is powerful enough to do message passing. It's method_missing, not method_received. You can't intercept message that already have a method defined for them. The sender chooses which method to call, and may call method_missing. It's not entirely up to the object how to respond to a message.

You can create a class which has no other methods than 'method_missing'. The explicitly declared methods are just useful syntactic sugar for how to respond to specific messages.

This sounds like the Event Bus (which can be implemented in an OOP language) to me.

Do people use that publish-subsribe model within a process rather than between processes? Any time I've encountered the 'event bus' model it's been for 'enterprise' (for lack of a better term) scale integration (i.e. gluing together applications across an organisation).

Sure, no matter what kind of programs. To get an idea, take a look at the example code at the end of the page: https://github.com/spinettaro/delphi-event-bus

4) Also, from a design point of view, the focus is a conversation of messages. Often the way people do "OO" is they focus on entities, not the messages and coversations.

By functions we generally mean "functions" which are stateless things which always return the same result to the same set of arguments.

Objects in contrast are not stateless things. They can know the history of the messages they have received earlier, as reflected in their internal state.

The distinguishing feature of message-passing an OOP I think is that the receiver of a message is free to decide how it will respond to it. Will it always return the same result for the same inputs? Not necessarily. I decides. It is the decider.

One way to think about Objects is as independent computers which get inputs from their surrounding and then somehow process such inputs. They might not return any result, but still do something useful. The point is they a PROGRAMMABLE objects, they are "live".

I have seen plenty functions on my career that are anything but stateless.

They may be called "functions" in the programming language you use but they are conceptually not "functions" as understood by the Functional Programming community and mathematics. This discussion about Alan Kay's "concept" of Object Orientation is much on the conceptual level, so we need to also consider that is the "concept" of 'Function'.

given everything thats been said here, i dont think comparing kay-objects and actors is a stretch. why do you think it is?

Because Alan Kay himself says that he drew a lot of inspiration from Hewitt's actor framework in developing object oriented programming.

Reply on news.ycombinator.com