On 8/20/2011 9:25 AM, John McKeon wrote:
On Sat, Aug 20, 2011 at 11:39 AM, Julian Leviston <[email protected]
<mailto:[email protected]>> wrote:
On 21/08/2011, at 12:22 AM, John McKeon wrote:
On Saturday, August 20, 2011, Alan Kay <[email protected]
<mailto:[email protected]>> wrote:
> (For example)
> Try to imagine a system where the parts only receive messages
but never explicitly send them.
> This is one example of what I meant when I requested that
computer people pay more attention to what is in between the
parts, than to the parts -- the Japanese have a great short word
for it: "ma" -- we don't, and that's a clue that we have a hard
time with "what is in between"
> Cheers,
> Alan
>
I like: the ether (it has a more Maxwellian flavor for me :)
Then try to imagine an object not in it
_______________________________________________
fonc mailing list
[email protected] <mailto:[email protected]>
http://vpri.org/mailman/listinfo/fonc
I find Alan's email slightly obscure - I thought I understood what
it meant... but then John, yours is so abstracted away from
anything I know to be in reality, that I find I don't really
understand Alan's email either. In concrete terms, what are you
talking about? Could you explain it simply?
What I thought Alan was talking about was just the reification of
message sending... but I think I'm totally lost now.
Sorry!
Thanks for asking Julian, I was in the middle of a follow-up message,
to explain myself, when your message appeared. You should be made
aware that Dr Kay's message grew out of the OOP
<http://vpri.org/mailman/private/fonc/2011/002593.html>thread from
yesterday. That email message led to spend half the night watching Dr
Kay's videos :) In the oopsla 97 keynote
<http://video.google.co.uk/videoplay?docid=-2950949730059754521> (I
think), he uses the word "interstitial" as an english translation for
/ma./ I thought of it differently, for a different point of view.
The ether was a term used by 20th century physicists to mean "that
stuff that makes up space". Newtonian mechanics kind of requires that
there be something there, through which light travels, or something
like that. So the messages are the ether, and the idea is that all
objects exists within it.
Dr Kay likes to use biological analogy for examples of truly well
designed systems. I like Astronomy, so I'm thinking Solar System.
Now try to think of the solar system without the sun - can't happen
(duh). But more importantly, there isn't an object in the system that
makes a move without the sun. The ether is what is between all the
objects (planets for one, humans and all other biological entities for
another) and the sun. How are the messages passed around?
I see two ways to model this. One is where the objects send messages
to the sun (give me light) and hope for a response. The other model
has the sun pumping out its messages "into the ether" to which all
objects may (or may not) respond. Much better scaling.
Take it to the biological analogy. One paradigm has each cell sending
messages back and forth, to and from the body (poor scaling), or it
can sit and listen to the flow of messages from the body and respond
when it deems it should ("Oh yes, I respond to the B12 message").
Of course, each object being its own sub-system, we can imagine each
having its own "topologically local" sun so our objects see only a
filtered stream of messages. The structures within any given cell
really only listen to its nucleus, say.
Just one of those blue moments? (See the video)
By way of a belated introduction, prior to that email I had only been
a lurker on this list for the past several weeks having come across it
after the Hasso-Plattner talk
<http://www.tele-task.de/de/archive/lecture/overview/5819/> (I've been
glued to it ever since :) I came to Squeak/Smalltalk four years ago
via Seaside for writing my CRUD apps on the web.
I hope you all don't mind me barging in here like that :)
a more concrete analogy comes to mind here (from the comment about the sun):
a physics engine.
for the most part, the "objects" in such a system are fairly passive,
but are mostly acted upon by the engine itself;
the engine goes and applies accelerations, checks for physical contacts,
applies contact forces, ...
and, meanwhile, the client mostly interacts with the objects:
setting up the objects (setting size/shape/mass/...);
fetching the current origin/velocity/rotation/...;
...
to a much lesser degree, the entity system in something like a game is
vaguely similar:
there are rarely interactions (as-in, method calls) directly between
entities.
( this came up recently off-thread: yes, I have written a basic
FPS-style 3D engine, and am trying to make a "playable" game based on
it, probably FPS style sort of like the Quake series or similar. I would
mention Doom 3, as my engine is more technically similar to this in many
ways, except my game mechanics/... are a bit closer to Quake 1/2 ).
far more often, calls are directed back towards more basic parts of the
engine, and then the engine may redirect messages back to the entities
themselves.
for example:
a rocket flies, and mostly sits there passively (its velocity/... cause
it to move forward);
the physics code sends it a message "hey, you have rammed into something";
it might decide whether to respond or ignore it ("what is this thing I
have rammed into?");
it may then cause damage, telling the engine that it is causing a
certain amount of damage over a certain radius at a certain location;
it then calls another piece of code: "ok, replace me with an explosion
effect".
elsewhere in the engine (in the explosion effect code):
it performs a radius-query (gets a list of everything within a given
radius of the origin);
for every item in the list:
checks if it can be damaged by an explosion (too far away? blocked?
...);
calculates how much damage each will receive (based on distance
from origin, ...);
makes another call "hey, this object was damaged for X HP".
the damage handler updates the entity's health/...
then it may notify the entity itself: "hey, you were damaged by X for Y
HP using attack Z".
the entity may evaluate the target, deciding whether or not to get mad
at them, ...
a partial reason most entities don't interact directly is that this
wouldn't really scale well, since most entities don't know about what
other sorts of entities they may interact with, so it is much more
preferable to try to be more "generic", and interact with entities more
in terms of general operations. typically, if an entity can't do
something, it will just ignore it.
so, most operations are more like "X is going on, are you going to do
anything?", rather than the more traditional model of "I command you to
do X, and then give me back a return value".
sadly, the actual implementation is far more crufty than this (and is in
large-part plain C), but this is the basic idea.
also:
code generally has to try to do operations quickly and then return (most
operations are fairly trivial, either changing entity state or setting
up subsequent events);
recursion is generally something to be avoided (most of this stuff is
non-recursive);
...
Happy trails,
John
Julian.
_______________________________________________
fonc mailing list
[email protected] <mailto:[email protected]>
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
