Hi Barry
I like your characterization, and do think the next level also will require a
qualitatively different approach
Cheers,
Alan
>________________________________
> From: Barry Jay <barry....@uts.edu.au>
>To: fonc@vpri.org
>Sent: Wednesday, February 13, 2013 1:13 PM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
>
>Hi Alan,
>
>the phrase I picked up on was "doing experiments". One way to think of
the problem is that we are trying to automate the scientific process,
which is a blend of reasoning and experiments. Most of us focus on one
or the other, as in deductive AI versus databases of common knowledge,
but the history of physics etc suggests that we need to develop both
within a single system, e.g. a language that supports both higher-order
programming (for strategies, etc) and generic queries (for conducting
experiments on newly met systems).
>
>Yours,
>Barry
>
>
>On 02/14/2013 02:26 AM, Alan Kay wrote:
>Hi Thiago
>>
>>
>>I
think you are on a good path.
>>
>>
>>One
way to think about this problem is that the broker is a human
programmer who has received a module from half way around the world
that claims to provide important services. The programmer would confine
it in an address space and start doing experiments with it to try to
discover what it does (and/or perhaps how well its behavior matches up
to its claims). Many of the discovery approaches of Lenat in AM and
Eurisko could be very useful here.
>>
>>
>>Another
part of the scaling of modules approach could be to require modules to
have much better models of the environments they expect/need in order
to run.
>>
>>
>>For
example, suppose a module has a variable that it would like to refer to
some external resource. Both static and dynamic typing are insufficient
here because they are only about kinds of results rather than meanings
of results.
>>
>>
>>But
we could readily imagine a language in which the variable had
associated with it a "dummy" or "stand-in" model of what is desired. It
could be a slow version of something we are hoping to get a faster
version of. It could be sample values and tests, etc. All of these
would be useful for debugging our module -- in fact, we could make this
a requirement of our module system, that the modules carry enough
information to allow them to be debugged with only their own model of
the environment.
>>
>>
>>And
the more information the model has, the easier it will be for a program
to see if the model of an environment for a module matches up to
possible modules out in the environment when the system is running for
real.
>>
>>
>>Cheers,
>>
>>
>>Alan
>>
>>
>>
>>>________________________________
>>> From: Thiago Silva <tsi...@sourcecraft.info>
>>>To: fonc <fonc@vpri.org>
>>>Sent: Wednesday,
February 13, 2013 2:09 AM
>>>Subject: Re: [fonc]
Terminology: "Object Oriented" vs "Message Oriented"
>>>
>>>Hello,
>>>
>>>as I was thinking over these problems today, here are some initial
thoughts,
>>>just to get the conversation going...
>>>
>>>
>>>The first time I read about the Method Finder and Ted's memo, I tried
to grasp
>>>the broader issue, and I'm still thinking of some interesting examples
to
>>>explore.
>>>
>>>I can see the problem of finding operations by their meanings, the
problem of
>>>finding objects by the services they provide and the overal structure
of the
>>>discovery, negotiation and binding.
>>>
>>>My feeling is that, besides using worlds as mechanism, an explicit
"discovery"
>>>context may be required (though I can't say much without further
>>>experimentations), specially when trying to figure out operations that
don't
>>>produce a distinguishable value but rather change the state of
computation
>>>(authenticating, opening a file, sending a message through the network,
etc)
>>>or when doing remote discovery.
>>>
>>>For brokering (and I'm presuming the use of such entities, as I could
not get
>>>rid of them in my mind so far), my first thought was that a chain of
brokers
>>>of some sorts could be useful in the architecture where each could have
>>>specific ways of mediating discovery and negotiation through the
"levels" (or
>>>narrowed options, providing isolation for some services. Worlds come to
mind).
>>>
>>>During the "binding time", I think it would be important that some
>>>requirements of the client could be relaxed or even be tagged optional
to
>>>allow the module to execute at least a subset of its features (or to
execute
>>>features with suboptimal operations) when full binding isn't possible --
>>>though this might require special attention to guarantee that eg.
disabling
>>>optional features don't break the execution.
>>>
>>>Further, different versions of services may require different kinds of
>>>pre/post-processing (eg. initialization and finalization routines). When
>>>abstracting a service (eg. storage) like this, I think it's when the
"glue
>>>code" starts to require sophistication (because it needs to fill more
>>>blanks)...and to have it automated, the provider will need to make
>>>requirements to the client as well. This is where I think a common
vocabulary
>>>will be more necessary.
>>>
>>>--
>>>Thiago
>>>
>>>Excerpts from Alan Kay's message of 2013-02-12 16:12:40 -0300:
>>>> 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
>>>> >
>>>> >
>>>> >
>>>> >
>>>--
>>>[]'s
>>>Thiago Silva
>>>http://www.metareload.com
>>>
>>>"We are either doing something or we are not; 'talking about' is a
subset of 'not'."
>>>_______________________________________________
>>>fonc mailing list
>>>fonc@vpri.org
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>>
>
>UTS CRICOS Provider Code: 00099F
>DISCLAIMER: This email message and any accompanying attachments may contain
>confidential information.
>If you are not the intended recipient, do not read, use, disseminate,
>distribute or copy this message or
>attachments. If you have received this message in error, please notify the
>sender immediately and delete
>this message. Any views expressed in this message are those of the individual
>sender, except where the
>sender expressly, and with authority, states them to be the views of the
>University of Technology Sydney.
>Before opening any attachments, please check them for viruses and defects.
>
>Think. Green. Do.
>
>Please consider the environment before printing this email.
>
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
