Please allow me to reset the discussion on this topic:

More and more I am wishing a design editor with YoYo-freedom in it:
To be more specific: I am not looking for a very sophisticated tool for high
educated programmers. I want a democratic tool that helps the domain-expert
to stay on the design-stage as long as possible: What happens now is that
they are invited to help design use-cases & helping to formalize
the first drafts of the (user)scenario's in interactiondiagrams. Then the
hard stuff of "real" engineering the design starts: the design team dig up a
lot of details and have to choose which details are more important for
modeling (time and money is always limited...) Even when he is allowed to
stay on the stage between all this detail-mess it is written down in complex
forms he does not recognise to mimic his problem, so how could he help to
choose...

I still like my old copy of the book "Designing Object-Oriented Software"
 (by Rebecca Wirfs-Brock c.s.) 
OK, the book (and other OO's )are less holy for me the ten years ago:
not chasing the holy grale of class-inheritence as a goal on itself, but as
a way to organize the growing complexity of your design (Multiple
inherentence did leave the stage as a to complex solution to implement.)

I did underline then sentences that I still care about:
- people understand the world by constructing mental models of it.
- mental models must be simpler then the systems they mimic ot they are
useless
- .... in this antropomorphic spriti, let's think of software as a living
thing
- it is the function of the domainexpert to provide the team with accurate
input about the details and particulary to abstract out which details are
the relevant ones.

- the - for me - most important concept of the book is that of the contract
between two objects(classes): not just sending messages, but designing a
culture of good behavior, where objects make agreements: If you ask me this
in such away then I promiss you that you get an answer in the format we
agree now on. Classes-Resposibilities-Contracts.

- Asynchroncity of the web was not a issue then, but I like the idea (in the
planner papers)  of giving each object an email-adress, so the message at
least will arrive and will be answered as soon that object has time. (I do
not have these papers, so if somenone knows agood introduction)

About that yoyo design editor: What I miss in Squeak is a tool that helps
you to organize your designprocess:
1. I want to start with a fast draft, global description, setting borders to
my project
2. Then I want to start the analysis: usecases, candidate objects,
scenario's, interactiondiagrams
3. Then I want to switch to the design: classes, behavior, atributes
(I like the design of Mark's CRC-tool BOOST with the switch between analysis
and design)  
4. but then: integrate with a UML-toolkit (in the past systemarchitect of
popkin did offer this, and Bjecteering of Softeam is reintroducing this
integration....
5. But I see no mapping to the design environment of Smalltalk 
6. And most important of all: i want to be able to yoyo:

start with an global overview, then goinig to the details and then BACK to
the overview. (To give you anexample of my own domain: "Ok, lets look what
course we did design untill now, I intended to design a course with a
studyload of 40 units, but end up in the details with 55... Where can I
adapt tasks on the lowest level to gat back to my intention... or should I
adapt my intention..)



> -----Original Message-----
> From: Justin Walsh [mailto:jwalsh at bigpond.net.au]
> Sent: zondag 14 oktober 2001 1:55
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Message passing rather than object orientation
> 
> 
> 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
> > > --
> > >
> > >
> >
> >
> 
> 
>