Unit tests are just a small part of the kinds of description that could be used
and are needed.
>________________________________
> From: David Harris <[email protected]>
>To: Alan Kay <[email protected]>; Fundamentals of New Computing
><[email protected]>
>Sent: Wednesday, February 13, 2013 7:39 AM
>Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>
>
>This sounds suspiciously like Unit Testing, which is basically "When I say
>this, you should answer that." Thos are precomputed answers, but could be
>computed I suppose -- so a bit like your Postscript example ... you send the
>Testing-Agent down the pipe.
>
>
>David
>
>
>
>On Wed, Feb 13, 2013 at 7:26 AM, Alan Kay <[email protected]> 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 <[email protected]>
>>>To: fonc <[email protected]>
>>>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 <[email protected]>
>>>> >To: Alan Kay <[email protected]>
>>>> >Cc: Fundamentals of New Computing <[email protected]>
>>>> >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 <[email protected]>
>>>> >>To: Fundamentals of New Computing <[email protected]>
>>>> >>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
<[email protected]> 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
>>>> >>>[email protected]
>>>> >>>http://vpri.org/mailman/listinfo/fonc
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>>
>>--
>>>> >>-Brian T. Rice
>>>> >>_______________________________________________
>>>> >>fonc mailing list
>>>> >>[email protected]
>>>> >>http://vpri.org/mailman/listinfo/fonc
>>>> >>
>>>> >>
>>>> >>
>>>> >_______________________________________________
>>>> >fonc mailing list
>>>> >[email protected]
>>>> >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
>>>[email protected]
>>>http://vpri.org/mailman/listinfo/fonc
>>>
>>>
>>>
>>_______________________________________________
>>fonc mailing list
>>[email protected]
>>http://vpri.org/mailman/listinfo/fonc
>>
>>
>
>
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
