I was imagining QuickCheck properties instead of unit tests...
On Wed, Feb 13, 2013 at 10:40 AM, Alan Kay <alan.n...@yahoo.com> wrote: > Unit tests are just a small part of the kinds of description that could be > used and are needed. > > ________________________________ > From: David Harris <dphar...@telus.net> > To: Alan Kay <alan.n...@yahoo.com>; Fundamentals of New Computing > <fonc@vpri.org> > 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 <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 > _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
