Message passing syntax for objects

[Tim Harig]

On 2013-03-18, Mark Janssen <dreamingforward at gmail.com> wrote:
> Alan Kay's idea of message-passing in Smalltalk are interesting, and
> like the questioner says, never took off.  My answer was that Alan
> Kay's abstraction of "Everything is an object" fails because you can't
> have message-passing, an I/O task, working in the same space as your
> objects -- they are two very different functionalities and they have
> to be preserved **for the programmer**.

Without concurrency, message passing and interacting through functions
are semantically similar.  You have operating for sending and receiving
messages.  Python does this through methods which potentially have inputs
and outputs.  Function syntax does have two slight advantages over pure
message passing.

1. A command is sent with the message as opposed to requiring requests to
	be parsed from the message separately from the data.

2. Functions constrain what actions are available and what inputs they can
	legal accept.  This is doubly true

With concurrency, CSP has shown us that message passing is valuable for
syncronization.  Most CSP languages retain the idea of passing messages.
This need not be the case.  The same semantics could be acheived through
function call syntax, although it would likely be less intuitive.

If you want to pursue your ideas further, and you have not already,
I suggest that you investigate Erlang and its CSP based "concurrent
oriented programming."  Alan Kay, himself, commented that he felt it
matched his ideas of message based OOP.  When you return, there is a
"Candygram" package providing similar constructs (last I knew, it did not
yet impliment light weight processes) for Python.

You might also look at using Go which has CSP based channel and coroutine
semantics.  It has many things in common with Python.