objects and messages

[RE01 Rice Brian T. EM2]

The continuing paradigm development...

>> 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?

Yes, with the intent towards the generalized message model of a
procedure query, where guarantees are only dynamic, even if that.  An
example is the matching of a software system's function with the user's
(abstract) request for an action (information update).
A more general example (and more meaningful) is the one involving the
fundamental relationship between humans and their machines, to which all
religions attempt to orthogonalize themselves (Jesus doesn't first-order
care about Tunes).  I speak of the metaphor used in 2001 (see
primate-and-bone ~= modern man and space-shuttle), involving the
positivistic (i.e. Descartes' positivism: 'I think ergo I am.')
paradigm, which denies the simulation of the world within the mind as a
mechanism for learning.  My thoughts on this simulation (class of
thoughts) is my own motivation for the Tunes method of computing
systems.  For better insight, read up on constructivism and
constructionism as meta-philosophical paradigms.

>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'll look at it as soon as I get the chance...

>> 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?

Just one use, I assure you.  Or perhaps this is simply a homo-iconic
metaphor: everything can be reduced to 'solving a problem'.  The
metaphor seems as inadequate as the functional homo-iconic metaphor
(discussed below), however.

>> *	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.

Yes, but the semantic definition of a function seems to require that a
function almost always accept and return objects of frighteningly high
order of uncountability in order to take on real importance (in a
homo-iconic metaphor), as I see it.  Hmm.  Then again, I could see that
passing types of continuations as messages (as well as other examples)
could result in uncountability among the homo-iconic object metaphor.
In the current machine model, I hope to address this by transporting the
uncountable structures to the machine model's implementation.  Perhaps
this is possible also in a functional paradigm with reflection.  Yes, my
intuition seems to agree with this tentative assessment.

>> *	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 :)

Cool.  I'll take a look before returning to this.

>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)

You are right by saying that everyone will want their own
metaphors/interfaces and put them into the system and be more productive
as a result.  Making Tunes ready for this is something I have been
looking at lately for the machine model (for interfaces).  Of course the
'interface' as a distinguishable type in our system will be rather
arbitrary with respect to the system logic.

>