Another object view - (was RE: copy yourself ?)

Adrian Sampaleanu adrian.s at sympatico.ca
Wed May 28 04:05:48 UTC 2003


 
> And I honestly cannot see ANY useful resemblance between
> computational objects and real physical objects.
> 
> Computational objects do not have mass; do not occupy space;
> do not emit or absorb photons (so don't have colour); it 
> makes no sense to ask about the velocity of sound through a 
> Workspace or the tension in a String.
> 
> Even in Morphic, which gives a pretty good illusion of
> reality, if you "drop" a morph, it doesn't fall.  The 
> "shadows" we see on the screen are totally unaffected by the 
> location of light sources in the room.

Richard, what you say is pretty valid if you tend to categorize what you
sense and think in the way most people do. Seeking to break things down
by differences helps us organize physical objects and abstract concepts.
You might disagree and say that you also aggregate like functionality in
your world view (at least among objects within either the real or
conceptual worlds bun not spanning both), but I wonder if you might see
some commonality between what seems to exist in the physical world and
what _could_ exist in the abstract one.
  
In my mind, one of the biggest problems which exists in software
development seems to be the inability to produce software of significant
compexity which can have a predictable failure rate or to be within a
measurable tolerance from some desired reference. Another goal that
seems to be ever elusive (at least on a larger and longer lasting scale)
is software modularity and re-use. Sure one could do some statistical
analysis of an application's output and assume that the data will hold
for all use cases, but this is usually not practical since the modes of
failure in software are so varied and constantly changing due to changes
in APIs, hardware, etc. My academic background, although never
practiced, is mechanical engineering, but I've spend my professional
life as a developer - not at the level practiced by many on this list,
so some of the following thoughts will probably sound naïve. But what
the heck... 

I've tried to see what basic analogy of the physical world we could
bring to software development and have some sense that there could be
some useful insights to be gained from nature yet the overall picture is
still vague. Certain people might be inclined to bring up various
references to papers discussing the differences between the disciplines
dealing with the concrete world and this one where we design and build
abstractions. From what I've read on the subject (not so much
unfortunately) these papers miss the point I'll try to get at below.

Here are some assertions about the "real" physically described world
that we might make. Of course this is not entirely accurate so feel free
to dispute these or to elaborate the details that I probably have
missed:

There are relatively few "object" properties in the physical world.
- mass/energy, density, refractive index, reflectivity, hardness,
chemical reactivity, electrical conductivity, magnetic properties,
position relative to some point of reference

The universe could be looked at as providing the environment of
interaction and determines how the properties of one "object" can affect
other objects' properties and defines the reference system in both space
and time. Pretty simplistic, I know, but it might be good enough to look
at it this way...
  
The rate of change (and the rate of change of the rates of change) of
these properties with respect to time might be viewed as additional
properties or not - not sure how to look at these for the point I'm
trying to make here, but in any case, the total number is still very
modest.

Based just on these properties, physical objects interact to create the
very rich, tactile (to a greater or lesser degree, using various
instruments) world we perceive with our senses.

The interactions that physical objects have with just this set of
properties is still what we could call useful (this is subjective, to be
sure) in terms of being significant steps in building higher level
assemblies that do something for us - this is a critical point, in my
opinion. For example, one mass impinging on another makes it move or
deform depending on the properties given above. Either of these is
something we can immediately "make use of" at the next level or we could
use the effect as is a quantum of usefulness.
 
What is a "good" thing might we say about the above? Even a very limited
set of object and environment properties which could be said to define
an interface or protocol for interaction, are enough to create a huge
variety of systems, and provide the basis for the scalability and
measurability of the higher level constructs.
 
In contrast, in the world of computing, at least at the implementational
level, we've allowed so many degrees of freedom in the basic building
blocks that it has become impossible to achieve massive scalability and
truly generic object re-use. 

I believe it was Alan (maybe Andreas) who commented some time ago that
having limited functionality in eToys would in some cases result in more
creative solutions to certain problems. Certainly it is nice from the
coder's (or user's/builder's) point of view if the building blocks are
all precisely what you need for any given problem, but (maybe from a
monk's point of view), a minimalist "object" view that provides just
enough variety to model a problem might allow for greater and more
stable layering of abstractions. In the real world, the complex physical
systems which have evolved or which we've built give us all the
complexity we could wish for, yet, even at higher levels, the object
interactions are based only on the properties described above. We manage
to perceive and extract more abstract, higher level functionality from
these nevertheless.

One might say so what? We've really simplified things even more in
computing - you have a bit or you don't. How much simpler can you get?
You could look at things that way, but it wouldn't be very helpful.
We're trying to get something of value from our physical world example
here, not challenge it just to be different. In the world of nuts and
bolts we do have sub-atomic particles that could form, if we chose that
level as a reference, the basic properties. So why not start there?
Because we, as human beings, work comfortably at a certain scale (and
less so at others). Therefore, we'll set the basic building block level
to be the one described above. Using these blocks we've managed to
re-create to a large degree what nature has created but at the same time
hasn't stopped us from exploring the world at scales below these blocks.

The question I've got - and to which I don't have an answer yet, is
where is the equivalent, useful, starting level of object abstraction
for information systems? Could we impose (because it might be
beneficial) a limited set of interfaces for objects to interact with at
this level and have these "written in stone"? In other words, could we
purposely put severe constraints on the possible interfaces for
interaction of the objects we choose as the basic blocks? What is the
equivalent - if there can be some kind of equivalence - to painting a
physical object in the bit world? Or of a force moving a mass? The
interactions between the physical objects is relatively simple in terms
of the properties described above, yet they provide us with a very
useful effects even at this lowest level.

What I'm thinking of is something like - If this basic piece of
information object is 'placed near' this GUI object, something 'useful'
(to us) should/could happen since the required interface 'surface' is so
small that some kind of interesting property transfer or effect
could/will happen". I think it might be useful to look at things from
this point of view even though the correspondence isn't one-to-one.

Well, at this point I think I'm rambling so I'll quit for now... Still,
I'd be interested in what anyone else has to say - even if it's a put
down ;-) Richard, if you aren't snoring by now, I'd welcome your opinion
since I regard your carefully analyzed and deliberate answers very
highly.

Adrian
 
 



More information about the Squeak-dev mailing list