Hi Jeff
I think "intermodule communication schemes" that *really scale* is one of the
most important open issues of the last 45 years or so.
It is one of the several "pursuits" written into the STEPS proposal that we
didn't use our initial efforts on -- so we've done little to advance this over
the last few years. But now that the NSF funded part of STEPS has concluded, we
are planning to use much of the other strand of STEPS to look at some of these
neglected issues.
There are lots of facets, and one has to do with messaging. The idea that
"sending a message" has scaling problems is one that has been around for quite
a while. It was certainly something that we pondered at PARC 35 years ago, and
it was an issue earlier for both the ARPAnet and its offspring: the Internet.
Several members of this list have pointed this out also.
There are similar scaling problems with the use of tags in XML and EMI etc.
which have to be agreed on somehow
Part of the problem is that for vanilla sends, the sender has to know the
receiver in some fashion. This starts requiring the interior of a module to
know too much if this is a front line mechanism.
This leads to wanting to do something more like LINDA "coordination" or
"publish and subscribe" where there are pools of producers and consumers who
don't have to know explicitly about each other. A "send" is now a general
request for a resource. But the vanilla approaches here still require that the
"sender" and "receiver" have a fair amount of common knowledge (because the
matching is usually done on "terms in common").
For example, in order to invoke a module that will compute the sine of an
angle, do you and the receiver both have to agree about the term "sine"? In APL
I think the name of this function is "circle 1" and in Smalltalk it's
"degreeSin", etc.
Ted Kaehler solved this problem some years ago in Squeak Smalltalk with his
"message finder". For example, if you enter 3. 4. 7 Squeak will instantly come
back with:
3 bitOr: 4 --> 7
3 bitXor: 4 --> 7
3 + 4 --> 7
For the sine example you would enter 30. 0.5 and Squeak will come up with:
30 degreeSin --> 0.5
The method finder is acting a bit like Doug Lenat's "discovery" systems. Simple
brute force is used here (Ted executes all the methods that could fit in the
system safely to see what they do.)
One of the solutions at PARC for dealing with a part of the problem is the idea
of "send an agent, not a message". It was quickly found that defining file
formats for all the different things that could be printed on the new laser
printer was not scaling well. The solution was to send a program that would
just execute safely and blindly in the printer -- the printer would then just
print out the bit bin. This was known as PostScript when it came out in the
world.
The "Trickles" idea from Cornell has much of the same flavor.
One possible starting place is to notice that there are lots more terms that
people can use than the few that are needed to make a powerful compact
programming language. So why not try to describe meanings and match on meanings
-- and let there be not just matching (which is like a password) but
"negotiation", which is what a discovery agent does.
And so forth. I think this is a difficult but doable problem -- it's easier
than AI, but has some tinges of it.
Got any ideas?
Cheers,
Alan
>________________________________
> From: Jeff Gonis <jeff.go...@gmail.com>
>To: Alan Kay <alan.n...@yahoo.com>
>Cc: Fundamentals of New Computing <fonc@vpri.org>
>Sent: Tuesday, February 12, 2013 10:33 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
>
>I see no one has taken Alan's bait and asked the million dollar question: if
>you decided that messaging is no longer the right path for scaling, what
>approach are you currently using?
>I would assume that FONC is the current approach, meaning, at the risk of
>grossly over-simplifying and sounding ignorant, "problem oriented languages"
>allowing for compact expression of meaning. But even here, FONC struck me as
>providing vastly better ways of creating code that, at its core, still used
>messaging for robustness, etc, rather than using something entirely different.
>Have I completely misread the FONC projects? And if not messaging, what
>approach are you currently using to handle scalability?
>A little more history ...
>
>
>The first Smalltalk (-72) was "modern" (as used below), and similar to Erlang
>in several ways -- for example, messages were received with "structure and
>pattern matching", etc. The language was extended using the same mechanisms ...
>
>
>Cheers,
>
>
>
>Alan
>
>
>
>>________________________________
>> From: Brian Rice <briantr...@gmail.com>
>>To: Fundamentals of New Computing <fonc@vpri.org>
>>Sent: Tuesday, February 12, 2013 8:54 AM
>>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>>
>>
>>Independently of the originally-directed historical intent, I'll pose my own
>>quick perspective.
>>
>>Perhaps a contrast with Steve Yegge's Kingdom of Nouns essay would help:
>>http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
>>
>>
>>
>>The modern post-Erlang sense of message-oriented computing has to do with
>>messages with structure and pattern-matching, where error-handling isn't
>>about sequential, nested access, but more about independent structures
>>dealing with untrusted noise.
>>
>>
>>Anyway, treating the messages as first-class objects (in the Lisp sense) is
>>what gets you there:
>>http://www.erlang.org/doc/getting_started/conc_prog.html
>>
>>
>>
>>
>>
>>
>>On Tue, Feb 12, 2013 at 7:15 AM, Loup Vaillant <l...@loup-vaillant.fr> wrote:
>>
>>This question was prompted by a quote by Joe Armstrong about OOP[1].
>>>It is for Alan Kay, but I'm totally fine with a relevant link. Also,
>>>"I don't know" and "I don't have time for this" are perfectly okay.
>>>
>>>Alan, when the term "Object oriented" you coined has been hijacked by
>>>Java and Co, you made clear that you were mainly about messages, not
>>>classes. My model of you even says that Erlang is far more OO than Java.
>>>
>>>Then why did you chose the term "object" instead of "message" in the
>>>first place? Was there a specific reason for your preference, or did
>>>you simply not bother foreseeing any terminology issue? (20/20 hindsight and
>>>such.)
>>>
>>>Bonus question: if you had choose "message" instead, do you think it
>>>would have been hijacked too?
>>>
>>>Thanks,
>>>Loup.
>>>
>>>
>>>[1]: http://news.ycombinator.com/item?id=5205976
>>> (This is for reference, you don't really need to read it.)
>>>_______________________________________________
>>>fonc mailing list
>>>fonc@vpri.org
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>
>>
>>
>>--
>>-Brian T. Rice
>>_______________________________________________
>>fonc mailing list
>>fonc@vpri.org
>>http://vpri.org/mailman/listinfo/fonc
>>
>>
>>
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
