[YoYo design] was RE: Message passing rather than object orientation

Justin Walsh jwalsh at bigpond.net.au
Sun Oct 14 22:36:42 UTC 2001



At last someone has noticed the King has no clothes!
This "simple" question has bugged the human species since the beginnings of
"civilisation".
We have not had much success: Britannica sums it up by saying we now live in
the post "enlightenment" period called (philosophical)Idealism (top-downers)
and (philosophical)Materialism (bottom-uppers).
Prior to that it was Rationalism and Empiricism. Both sides still do just
what they have always done, slug it out (natural dialectic).
In Gullivers Travels it was (ironically) over which end of the egg to crack
open first.
All the "Intellectuals" behind Smalltalk, nay all western (not eastern)
science and technology are chained to the British Empirical Method:
suck-it-n-see-ism, wyswyg-ism, habit-ualism,
production-for-productions-sake. Frenetic mindless action-ism:
industry....all mere proto-religions! Debono "The Happiness Purpose"
This point-of-viewing  the objective world does not tolerate reasoning.
Lateral thinking perhaps.
Which is afterall what (I think) you are demanding.
I know of only one other person from the pre-RDBMS days who took a
Copernican approach to the problem. I researched him and his methodology
for ten years, giving it 8 out of 10.
Unfortunately he had committed himself to Omnis (unaware of Smalltalk or
Prolog). If he had known any of these options the score would be 10 out of
10.
I'm trying to get him to convert to Smalltalk but he is too old and tired
(like me) to bother fighting another crowd of (bottom-dwellers).
Don't hold your breath waiting for an answer.
good luck
Attached are some of my favorite tools and references: more if you want. But
Newton, Hume, Rosseau, Leibnitz (Deutsch) Leibniz (English), Kant are the
major influence on modern thinking. Charlemagne is responsible the
Scholastic System which still shackles our mind.
If Alan had read Kant (thoroughly) he might not be in the pickle he in now.
It is never too late. I was over 50 before I took the plunge.

----- Original Message -----
From: <G.J.Tielemans at dinkel.utwente.nl>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, October 14, 2001 10:45 PM
Subject: [YoYo design] was RE: Message passing rather than object
orientation


> 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
> > > > --
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kant's Critique of Pure Reason.url
Type: application/octet-stream
Size: 154 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/KantsCritiqueofPureReason.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Critique of Pure Reason Norman Kemp Smith.url
Type: application/octet-stream
Size: 152 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/CritiqueofPureReasonNormanKempSmith.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Welcome - Ripose.url
Type: application/octet-stream
Size: 108 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/Welcome-Ripose.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Encarta Homepage.url
Type: application/octet-stream
Size: 142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/EncartaHomepage.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Rousseau, Jean Jacques, an Encarta Encyclopedia Article Titled Rousseau, Jean Jacques.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/RousseauJeanJacquesanEncartaEncyclopediaArticleTitledRousseauJeanJacques.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Leibniz, Gottfried Wilhelm, an Encarta Encyclopedia Article Titled Leibniz, Gottfried Wilhelm.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/LeibnizGottfriedWilhelmanEncartaEncyclopediaArticleTitledLeibnizGottfriedWilhelm.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Hume, David, an Encarta Encyclopedia Article Titled Hume, David.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/HumeDavidanEncartaEncyclopediaArticleTitledHumeDavid.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Newton, Sir Isaac, an Encarta Encyclopedia Article Titled Newton, Sir Isaac.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/NewtonSirIsaacanEncartaEncyclopediaArticleTitledNewtonSirIsaac.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kant, Immanuel, an Encarta Encyclopedia Article Titled Kant, Immanuel.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/KantImmanuelanEncartaEncyclopediaArticleTitledKantImmanuel.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Charlemagne, an Encarta Encyclopedia Article Titled Charlemagne.url
Type: application/octet-stream
Size: 194 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011015/c84ac62e/CharlemagneanEncartaEncyclopediaArticleTitledCharlemagne.obj


More information about the Squeak-dev mailing list