>From my last trip to the SPLASH conference a few years ago, I've been contemplating a lot of these ideas. Especially the messaging paradigm and the current conundrum with concurrency and scaling. A common theme (brought up by Ivan Sutherland paraphrased here) is that in the past processing was expensive, now its communication. From the sheer amount of development code and processing done to pack up data in an understandable form, serialize it, encrypt it, etc so it can get to another component to process (at least at the macro distributed systems level). Now it's a concern with the multi-core processors that need to process data. I went to some of the workshops on the functional languages and Actors as a way to handle some of these issues through asynchronous messaging.
My thought, but I've not found much work in this area is in this era of virtualization, a small program or service can be instantiated anywhere as long as location independence is honored. So why not do a lot of the "distributed work" by instantiating these services to where a majority of the data is located. Sure there will be times when it needs to be shipped somewhere, but most of the communication needed would be smaller control data to coordinate the program instantiations and handoff (Like some of the IPC work I used to do with unix processes using semaphores). The most significant con I see to this is handling fault tolerance so there are no deadlocks. I realize there are much more experienced smart people on this forum that could shoot some holes in this approach, and I invite you to do so. My feeling won't be hurt as long as I can learn some more. Most of my experience is in the boring arena of Business IT (with my earlier years in Defense with Simulators and Communication Systems). Thanks for any reply, John Brown On 2/13/13 5:09 AM, "Thiago Silva" <tsi...@sourcecraft.info> wrote: >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.h >>>>tml >> >> >> >> >> >> >> >>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
