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 <alan.n...@yahoo.com> 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 > > > > _______________________________________________ > fonc mailing list > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
