One of the motivations is to handle some kinds of scaling more gracefully. If 
you think about things from a module's point of view, the fewer details it has 
to know about resources it needs (and about its environment in general) the 
better. 

It can be thought of as a next stage in going from explicit procedure calls 
(where you have to use the exact name) to message passing with polymorphism 
where the system uses context to actually choose the method, and the name you 
use is (supposed to be) a term denoted a kind of goal (whose specifics will be 
determined outside the module).

If you can specify what you *need* via a description, you can eliminate even 
having to know the tag for the goal, the system will still find it for you.

Another way to think of this is as a kind of "semantic typing"

This could be a great idea, because a language for writing descriptions will 
almost certainly have fewer things that have to be agreed on globally, and this 
should allow more graceful coordinations and better scaling.

However, this has yet to be exhibited -- so it needs to be done and critiqued 
before we should get too excited here.

I think a little $ and a lot of work in CYC or Genesereth's game language would 
be a good first place to start. For example, in CYC you should be able to write 
a description using the base relational language, and Cyc should be able to 
find you the local terms it uses for these

Cheers,

Alan




>________________________________
> From: Casey Ransberger <casey.obrie...@gmail.com>
>To: Fundamentals of New Computing <fonc@vpri.org> 
>Sent: Monday, March 19, 2012 3:35 PM
>Subject: [fonc] Publish/subscribe vs. send
> 
>Here's the real naive question...
>
>I'm fuzzy about why objects should receive messages but not send them. I think 
>I can see the mechanics of how it might work, I just don't grok why it's 
>important. 
>
>What motivates? Are we trying to eliminate the overhead of ST-style message 
>passing? Is publish/subscribe easier to understand? Does it lead to simpler 
>artifacts? Looser coupling? Does it simplify matters of concurrency?
>
>I feel like I'm still missing a pretty important concept, but I have a feeling 
>that once I've grabbed at it, several things might suddenly fit and make sense.
>_______________________________________________
>fonc mailing list
>fonc@vpri.org
>http://vpri.org/mailman/listinfo/fonc
>
>
>
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to