objects and messages
Tril
dem@tunes.org
Sun, 25 Oct 1998 18:07:36 -0800 (PST)
On Sat, 17 Oct 1998, RE01 Rice Brian T. EM2 wrote:
> The usual approach to dealing with this space of working with computers,
> that of communicating goals or information updates, is usually
> accomplished by the object-message ontology. By this, I am not only
> referring to the usual object-oriented programming methods that we are
> so familiar with today, but the entire paradigm for programming which
> has been in use since machines have been developed (this includes most
> all of human social development in eastern, western, and associated
> cultural systems). The 'fine-grain' project goal of the Tunes attempts
> to address this system's inherent lack of utility.
You didn't explain how message passing is equivalent to the paradigm since
machines were developed. I assume you mean the "procedure call" paradigm.
Message passing is often looked at as a procedure call. Is this what you
mean?
Make sure to read the paragraph starting with "Message passing" in
the following message:
http://www2.tunes.org/cgi-bin/wilma_hiliter/tunes/9505/msg00031.html?line=148#hilite
> I intend to explicate the metaphor between a system of objects sending
> messages to each other in order to perform some sort of computation with
> the higher-level idea of the logic of problem-solving in mathematical
> spaces. Here are some elements of the metaphor:
Does the entire system have to be "problem-solving"? Or is that just one
use?
> * refine the object-message paradigm explanation and embed linear and
> non-linear problem-solving into the traditional object ontologies for
> programming systems, including the usual ones seen in commercial
> environments (ugh) (e.g. SmallTalk, Self, BeOS, NeXTSTEP, Beta, and
> Windows (shiver)) as well as the ones implicit in the human-computer
> interaction model.
Do you agree message passing is just one way of looking at computing, and
an equally valid way is functional programming? Functional programming
should relate to your mathematical problem solving equally as well.
> * address the Self paradigm of programming, as well as the Lisp and C
> styles.
There are LOTS of messages in the archive about SELF. And if that's not
enough, Jecel can find you more :)
I think paradigm should include both the IDEAS the language was
designed to embody (the programming style favored by the language), and
the way people actually use the language. Remember, TUNES is a hacker
system, which means: People will always use software for things it was
not intended. TUNES will encourage and assist this creative use of
components, instead of discouraging it like other systems do (by design or
by accident).
David Manifold <dem@tunes.org>