[Python-ideas] Message passing syntax for objects

[Haoyi Li]

> Well this is where it gets bizarre to me.  Because, despite threading,
the CPU still has to dispatch all processes and handle the data passing,
ultimately.

Yeah. It works automagically, though, really nicely. It means I don't need
to mess around with a huge spaghetti of locks and mutexes and semaphores
when i want to use multiple cores. Although the CPU has to handle all the
processes and data passing, the programmer (almost) doesn't have to. That's
a pretty big gain.

> Well, I argue that in the world of programming language evolution, all of
these, except for the last, are premature optimizations.

I dunno, lots of people like event loops, not just the scala actors people:
Go's goroutines, python's greenlets, ruby fibers, etc. are all doing this.
They provide nice correctness (no pre-emption causing race conditions) and
performance (OS threads are heavy!) characteristics. Looking at the
"message passing" systems I know about:

- Erlang processes
- Go goroutines
- Scala actors
- Obj-C objects

3 out of 4 are basically using it for concurrency, for isolating mutable
state and providing the multi-thread-serializable-calling behavior you
called "bizarre". This is just to back up my claim that the things
Scala-actors (and the other message passing systems above) give you w.r.t.
concurrency is actually *really nice*, and even if you don't see the
benefits, they're there and people love them.

> How can you use a list comprehension unless you know the length or depth
of each sub-list?

The most common cases are non-recursive data structures, so I already know
their depth, the less common case is recursive data structures, and I
recurse on them; people do it all the time. I mean you could encapsulate
the recursion in a method which calls itself on its children, or you could
ask for its children in your function and recurse on them yourself. Neither
is really better or worse, just different approaches with different
tradeoffs.

> Where that where the ClassName and the Class.__doc__ should get you half
the way there.  There necessary component would be a universal/abstract
data type.  I propose a FractalGraph which can handle and scale any level
of complexity. As long as we have a universal data type, the class
hierarchy that emerges will be simple and general to handle, rather than
dealing with personal taxonomies.

Isn't the idea of an "object" with "methods" and "fields" basically that
universal data type? How is it yours will scale to any level of complexity
and be simple and general to handle but the "object" universal data type
doesn't?

> No.  While you're technically correct as to the issue of isomorphism.  In
practice, the usage you propose does not help whatsoever.  "(mgs, a, b)" is
too complex.  Firstly, in the message-passing scheme I'm proposing, you
never pass in more than one piece of data, unless it's a very structured,
perhaps (a single XML-like tree?).

Is the proposal basically to use shorter methods with fewer parameters? I
mean, a list of arguments (which could be objects and contain other objects
inside) sounds exactly like an XML-like tree to me.


Here's an interesting question: Is there any existing language/system out
there, that's built in the manner you describe (message passing etc.),
which you can point at and say "see, they do it this way and it works much
better"? That would help immensely in understanding what benefits you're
envisioning, since I (and others?) apparently don't see them






On Thu, Mar 21, 2013 at 6:22 PM, Mark Janssen <dreamingforward at gmail.com>wrote:

> On Thu, Mar 21, 2013 at 11:08 AM, Haoyi Li <haoyi.sg at gmail.com> wrote:
>
>> There are basically two discussions happening here: ADTs (small objects
>> with public contents) vs Encapsulation, and method calls vs message sends.
>> A few responses:
>>
>> Thank you.  You've boiled the discussion down to the two main elements.
>  Abstract data type's (which I was calling "prototypes")  vs. Encapsulation
> is the important distinction.  It's not an easy distinction to see from the
> words alone.  The former, I'll say, is built from the ground (the bits)
> upwards, while the latter, while the latter from the top (the
> application-layer), downwards.  But, I wouldn't say that for ADTs that
> public contents were the important part.  In fact, I'd argue the opposite.
>
>
>> >> or ensuring messages are handled serially per-object,
>>
>> >This happens in either paradigm.
>>
>> I mean that messages sent *from multiple threads *are handled serially.
>>
>
> Well this is where it gets bizarre to me.  Because, despite threading, the
> CPU still has to dispatch all processes and handle the data passing,
> ultimately.
>
>
>>  If your entire program is single threaded (as many python programs are)
>> or has a GIL which prevents multiple concurrent method calls, then i guess
>> it isn't a big deal. But in a language that does have pre-emptive
>> multithreading, this basically gives you a non-blocking, guaranteed
>> (because there's no other way to interact with the object other than
>> sending messages) "lock" around each object. Each object basically gets:
>>
>> - its own single-threaded event loop to run its methods
>> - without the performance hit of creating lots and lots of threads
>> - without the overhead of running multiple processes and IPC betweeen the
>> one-thread-per-process event loops (twisted, node.js, etc.) when you want
>> to utilize multiple cores
>> - with minimal overhead over standard method calls (both syntactic and
>> performance)
>> - for zero effort on the part of the programmer
>>
>
> Well, I argue that in the world of programming language evolution, all of
> these, except for the last, are premature optimizations.
>
>>
>> >Yes, and here is where something significant I think will happen.
>> >Complicated data structures just simply don't get re-used.  Python
>> >allows lists within lists within lists, but any program that uses that
>> >outside of n x n matrices won't ever get re-used ever.  Because there
>> >is no unified data model.
>>
>> I disagree completely. Coming from Java, where every list-within-list has
>> its own special class to represent it, my experience is that is a terrible
>> idea:
>>
>>
> - Want to convert from one list-within-list to another list-within-list?
>> Use a list comprehension and be done with it. Want to convert a special
>> InsnList to a special ParameterList? Much more annoying.
>>
>
> How can you use a list comprehension unless you know the length or depth
> of each sub-list?
>
>
>> It's not like encapsulating the whole thing makes the data struture any
>> less complicated: it just makes it more annoying to do things with, because
>> now I have to learn *your* way of doing things rather than the standard
>> python-list way of doing things.
>>
>
> Where that where the ClassName and the Class.__doc__ should get you half
> the way there.  There necessary component would be a universal/abstract
> data type.  I propose a FractalGraph which can handle and scale any level
> of complexity. As long as we have a universal data type, the class
> hierarchy that emerges will be simple and general to handle, rather than
> dealing with personal taxonomies.
>
>
>> In the end, message sends and method calls are basically isomorphic, so
>> much so that in Scala you can transparently convert method calls to
>> message sends under the hood<http://doc.akka.io/docs/akka/2.1.0/scala/typed-actors.html> if
>> you prefer that syntax! Unless there's some significant advantage of doing
>> it, it seems to me that the improvement would basically be forcing people
>> to run a regex on their code to convert obj.method(a, b) to obj << (msg, a,
>> b), and then life goes on exactly as it did before.
>>
>
> No.  While you're technically correct as to the issue of isomorphism.  In
> practice, the usage you propose does not help whatsoever.  "(mgs, a, b)" is
> too complex.  Firstly, in the message-passing scheme I'm proposing, you
> never pass in more than one piece of data, unless it's a very structured,
> perhaps (a single XML-like tree?).
>
> mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130321/050cb250/attachment.html>