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