6 ms·

> The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC ph

by pacala 11y ago

> The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak is all about (and it's something that was never quite completed in our Xerox PARC phase). The Japanese have a small word - ma - for "that which is in between" - perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. Think of the internet - to live, it (a) has to allow many different kinds of ideas and realizations that are beyond any single standard and (b) to allow varying degrees of safe interoperability between these ideas. What is the difference between "messaging" and "function call"? "messaging" data into a module = call a function with the data as arguments. "messaging" data out of a module = package the data as the return of the function.

contingencies 11y ago
Think of the internet... Great quote along these lines is: Upgrade cost of network complexity: The Internet has smart edges ... and a simple core. Adding an new Internet service is just a matter of distributing an application ... Compare this to voice, where one has to upgrade the entire core. - RFC3439 (2002) ... from my fortune clone @ https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup
frik 11y ago
> What is the difference between "messaging" and "function call"? If the object supports the message, then it will execute some code. Otherwise it will just ignore it. This is a more dynamic approach than an explicit function/method call where the object must support that function. You can think of e.g. Javascript events plus function calls (callbacks) that pass an object ("message") and a typeof/switch check as an equivalent.
sitkack 11y ago
Messaging is a protocol level abstraction, communication between entities [1]. A function call is a much lower level abstraction that does a <verb> to/with the data. One could have an entity that executes one function or many, or it could manage a whole sequence of events. The Kay Object (KO) is more of an encapsulated microservice, like an Erlang process. How would mail (SMTP) look if it was implemented via RPC? [1] I specifically didn't use the word object because the Kay Object and the Java/C++ object are not comparable.
wpietri 11y ago
You should take a look at the Reactive Manifesto [1] and the actor model [2]. My own personal and non-expert take is that message orientation is about the wholeness of the actors that pass messages. "Would you care for a drink?" is message oriented. Whereas many systems built on function calls are more like you jabbing me in the butt with a syringe filled with 20 ccs of alcohol. [1] http://www.reactivemanifesto.org/ http://www.reactivemanifesto.org/ [2] http://www.infoq.com/news/2014/10/intro-actor-model http://www.infoq.com/news/2014/10/intro-actor-model
praptak 11y ago
Function call usually means static binding (call a specific address) or at best a virtual call (call address from a vtable). Messaging is much more flexible - the receiver can have a custom dispatch function that looks at the message and chooses the implementation in a Turing-complete way (like "call foo if third argument is 7, bar otherwise"), logs the message, duplicates it to send to multiple implementations, serializes it to send over the network, whatever. Obviously for this to be efficient, the underlying system often optimizes "sending a message" to "calling a function".
arethuza 11y ago
My own personal view is: - function calls: single recipient, return values, synchronous - messaging: publish & subscribe, no return value, asynchronous Also - using pure message passing "inside" a component is kind of painful, using pure function calls between components can be painful. Of course, this depends on your definition of "component"....
peter303 11y ago
Messages and function calls are similar but interpreted at different times. In a OOP like Java the method is usually set at compilation. In Smalltalk or ObjectiveC the method is interpreted when the program is run. A class may not even know the method and either ignore it or handle it. Delayed binding gives more flexibility in designing class and increases the chance of runtime errors. In the olden days delayed binding made programs slower and executables larger. But that isn't much of an issue now.
deleted 11y ago
[deleted]
adamwathan 11y ago
I think about conceptually like this... When one object is "calling a function" inside of another object, it's reaching into that object, grabbing the method it wants to invoke, and invoking it. It puts the responsibility of invoking that method on the caller. When one object "sends a message" to another object, the receiving object is responsible for determining what function gets invoked. The most obvious place this difference manifests itself is the existence of things like "method_missing". That can't happen when you're "calling a function", but if you're just sending a message and the receiving object doesn't have a method that matches the message name, it can still make a decision about how to respond.
Animats 11y ago
Kay's use of "messaging" started early; he'd talk about "sending a message to a number to add a value to itself". It sounded like there were all these asynchronously running objects communicating. That was his original vision - every object a virtual CPU. But in reality, it was just a synchronous function call. The funny thing is, we now do have a lot of systems that are async message-oriented. Mostly in Javascript, not Smalltalk. You send a one-way message to something, and maybe it calls you back later.

by pacala 11y ago

contingencies 11y ago

Think of the internet... Great quote along these lines is: Upgrade cost of network complexity: The Internet has smart edges ... and a simple core. Adding an new Internet service is just a matter of distributing an application ... Compare this to voice, where one has to upgrade the entire core. - RFC3439 (2002) ... from my fortune clone @ https://github.com/globalcitizen/taoup https://github.com/globalcitizen/taoup

frik 11y ago

> What is the difference between "messaging" and "function call"? If the object supports the message, then it will execute some code. Otherwise it will just ignore it. This is a more dynamic approach than an explicit function/method call where the object must support that function. You can think of e.g. Javascript events plus function calls (callbacks) that pass an object ("message") and a typeof/switch check as an equivalent.

sitkack 11y ago

Messaging is a protocol level abstraction, communication between entities [1]. A function call is a much lower level abstraction that does a <verb> to/with the data. One could have an entity that executes one function or many, or it could manage a whole sequence of events. The Kay Object (KO) is more of an encapsulated microservice, like an Erlang process. How would mail (SMTP) look if it was implemented via RPC? [1] I specifically didn't use the word object because the Kay Object and the Java/C++ object are not comparable.

wpietri 11y ago

You should take a look at the Reactive Manifesto [1] and the actor model [2]. My own personal and non-expert take is that message orientation is about the wholeness of the actors that pass messages. "Would you care for a drink?" is message oriented. Whereas many systems built on function calls are more like you jabbing me in the butt with a syringe filled with 20 ccs of alcohol. [1] http://www.reactivemanifesto.org/ http://www.reactivemanifesto.org/ [2] http://www.infoq.com/news/2014/10/intro-actor-model http://www.infoq.com/news/2014/10/intro-actor-model

praptak 11y ago

Function call usually means static binding (call a specific address) or at best a virtual call (call address from a vtable). Messaging is much more flexible - the receiver can have a custom dispatch function that looks at the message and chooses the implementation in a Turing-complete way (like "call foo if third argument is 7, bar otherwise"), logs the message, duplicates it to send to multiple implementations, serializes it to send over the network, whatever. Obviously for this to be efficient, the underlying system often optimizes "sending a message" to "calling a function".

arethuza 11y ago

My own personal view is: - function calls: single recipient, return values, synchronous - messaging: publish & subscribe, no return value, asynchronous Also - using pure message passing "inside" a component is kind of painful, using pure function calls between components can be painful. Of course, this depends on your definition of "component"....

peter303 11y ago

Messages and function calls are similar but interpreted at different times. In a OOP like Java the method is usually set at compilation. In Smalltalk or ObjectiveC the method is interpreted when the program is run. A class may not even know the method and either ignore it or handle it. Delayed binding gives more flexibility in designing class and increases the chance of runtime errors. In the olden days delayed binding made programs slower and executables larger. But that isn't much of an issue now.

deleted 11y ago

[deleted]

adamwathan 11y ago

I think about conceptually like this... When one object is "calling a function" inside of another object, it's reaching into that object, grabbing the method it wants to invoke, and invoking it. It puts the responsibility of invoking that method on the caller. When one object "sends a message" to another object, the receiving object is responsible for determining what function gets invoked. The most obvious place this difference manifests itself is the existence of things like "method_missing". That can't happen when you're "calling a function", but if you're just sending a message and the receiving object doesn't have a method that matches the message name, it can still make a decision about how to respond.

Animats 11y ago

Kay's use of "messaging" started early; he'd talk about "sending a message to a number to add a value to itself". It sounded like there were all these asynchronously running objects communicating. That was his original vision - every object a virtual CPU. But in reality, it was just a synchronous function call. The funny thing is, we now do have a lot of systems that are async message-oriented. Mostly in Javascript, not Smalltalk. You send a one-way message to something, and maybe it calls you back later.