Agree with everything Peter says. I used RDD with ball and arrow
object interaction diagrams. We did not write one line of code
without "seeing" the object interaction first. I also kept index cards
handy and a koosh ball. Some folks are fundamentally kinesthetic.
Role playing the object interaction helps lots of folks break through
their mental barriers. The koosh ball represents the locus of execution...
passing with each message send and the index cards represent the
behaviors of the individual objects that receive messages in the
course of the interaction. With the focus shifted to "who knows how
to do what for whom?" people start grokking the essence of object design.

Going from object interaction diagram to Smalltalk code is a mechanical
process in which the instructor gets to ask illuminating questions like,
"Which object does the next message arrow point to?" <the receiver>
"What message is being sent next?" <the message>
"Is there an interesting return value?" <return or assign result>

The fact that this is stone simple is perhaps one of the most frustrating
things to an "experienced programmer." I also promoted values of design
early and often. Validate design ideas with simple and direct
implementations early and often.

John Sarkela
"Trained a few smalltalkers myself."

> From: Peter Crowther <Peter.Crowther at IT-IQ.com>
> Reply-To: squeak at cs.uiuc.edu
> Date: Tue, 22 Feb 2000 10:25:22 -0000
> To: "'squeak at cs.uiuc.edu'" <squeak at cs.uiuc.edu>
> Subject: Re: How about Smalltalk-2000?
> Resent-From: squeak at cs.uiuc.edu
> Resent-Date: 22 Feb 2000 10:31:11 -0000
> 
>> According to recent reports here,
>> beginners pick up on the syntax of Smalltalk and the concepts
>> of object
>> oriented development faster/better than do more experienced
>> programmers.
> 
> Yep.  I used to teach Smalltalk.  It's like teaching event-driven
> programming, logic programming, or functional programming: you have to shake
> an existing programmer loose from his/her preconceptions before you can get
> anywhere.  In a 3-day course, we did half a day of O-O concepts and design,
> one short session on language syntax (as a professional trainer, I *love*
> small languages; they're so easy to teach), the rest of Day 1 on the browser
> and creating a noddy class, and then the whole of the rest was exercises
> around learning the class library.  The worst part was always the O-O
> design, and the extreme misconceptions that people came in with.  Yes, even
> the experienced C++ developers in some cases --- I've had people leave that
> course saying they'd learned a lot to apply to C++ class development.
> 
> My approach to shake people loose?  Teach them a modelling paradigm, whether
> UML, ERA modelling, point-and-name... but make sure they grok object/message
> before you carry on.  Bring a hen's egg into the course (preferably
> hard-boiled, if you're as bad at juggling as I am) and point out
> interface/code/data as shell/albumen/yolk.  Ask someone to do something
> (rather than telling them) and point out the similarity to a message send as
> a request.  Real-world examples are good.  Once programmers find out that
> instances act very much like people communicating (you ask, you can't invade
> their privacy, they can delegate, you get a reply from them), they have an
> internal model from which they can work.
> 
> Oh dear... I'll just climb down off the soapbox again.
> 
> - Peter
>