Hi!
I agree with you about "more intentional and strategic forms of
programming".
The attached .gif demonstrates that ken is on the right "intentional" track
but, on the wrong "practical" track ie.
The former is analytic the latter synthetic, (pattern, state, be-ing, mvc)
as distinct from (action, transition, be-coming, morphic).
The former are the objects of pure, a prior, reasoning the latter objects of
practical, posteriori, reasoning.
The former declarative, the latter procedural.
If the intention is to isolate, or seek out real "public" objects with a
device like morphic then it won't work.
Sure! you will expand the number of principles and concepts (as if we need
any more) but never leave the current universe of discourse: play.
Intention and strategy is another domain altogether.
Sorry morphers Etoys is as good as it is going to get.
" a cluster of small hills doth not a mountain make"
cheers
Justin



----- Original Message -----
From: <G.J.Tielemans at dinkel.utwente.nl>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, October 14, 2001 3:00 AM
Subject: RE: Message passing rather than object orientation


>
> > Most of the Hewitt Actor papers are really worth reading -- as are
> > the preceeding PLANNER papers (from which I adapted many ideas for
> > Smalltalk-71, which we never got around to implementing). I agree
> > very much with Ken Kahn (and have agreed with him for many years),
> > that what we need is a more intentional and strategic form of
> > programming.
> >       Carl Hewitt has never gotten the credit he deserved for being a
> > pioneer in this form of programming (with PLANNER). If you combine
> > this style with objects -- If you really make object-methods goal
> > satisfiers, etc.,
>
> Found on: http://www-osl.cs.uiuc.edu
>
> In the Actor model of Computation [Hewitt'77, Agha'85]:
> -  An actor is a reactive entity.
> -  In response to a message, an actor can:
>             - Create a new actor,
>             - Send a message to an acquaintance actor, or
>             - Change its internal behaviour.
>
> Asynchronous Buffered Messages
> -  Actors have unique mail addresses.
> -  Messages (potential method invocations) are buffered in a mailbox.
> -  Actors communicate only via asynchronous message passing.
> -  In the actor model, there is guaranteed message delivery.
>
> Synchronizers
> -  Synchronizers are linguistic constructs used to coordinate actor
> interactions [Frolund'96].
> <Put constr.gif here>
>
> Casts
> -  A cast is a group of actors that encapsulates synchronization for those
> actors.
> -  An actor can not belong to more than one cast.
> -  A cast of actors may have one or more directors.
>
> Is this what you were looking for?
>
> (Rebecca Wirfs-Brock: "It is the function of the domain expert to provide
> the team with accurate input about the details, and particularly to
abstract
> out which details are the relevant ones."
> Not just sending messages but creating contracts between objects is the
core
> of her CRC-technics. The problem is the gap between using crc-crads for
the
> first design-draft and the details that pop-up during the next steps: how
to
> communicate these back to the domain-expert, so he can choose again? )
> > then you get into a much better place for
> > programming in general. This was what ST-71 was all about. We always
> > encourage Smalltalkers to program as if they are satisfying goals
> > with methods, but this is kind of weak tea without extensive language
> > support.
> >       Ken has done a number of languages over the years that have
> > shown many interesting insights about this way to program. One of
> > them was a language called VULCAN -- and there are several good
> > papers that he wrote about these languages (maybe we can get him to
> > give us URLs if they are online).
> >
> > >
> > >>Recently Andreas Raab has done some remarkable experiments with
> > >>very large numbers of very low overhead processes in Squeak which
> > >>bodes well for the future.
> > >
> > >I am still not quite sure for what specific problems large numbers
> > >of processes are a good solution.  Computing propagation patterns
> > >on-the-fly and interleaved with the computation carried out by the
> > >message payload may be one case, but many/most practical cases seem
> > >to be solvable without the need for concurrency.
> >
> > It's not so much about concurrency as about environments. And it's
> > not so much about solution as realization.
> >
> > Cheers,
> >
> > Alan
> > --
> >
> >
>
>