Smalltalk thinking style (was: newbie question)

Terry Raymond traymond at ids.net
Wed Jul 14 02:17:13 UTC 1999


On Tue, 13 Jul 1999 09:53:31 +0930, Peter Smet wrote:

>
>>Ken:
>>
>>Although I think the...advice...the others have given you is correct, I
>also think
>>that it was...put too strongly.  Please don't feel bad, and please don't
>stop
>>experimenting.  Yes, you'll make mistakes, but that's just part of the
>learning
>>process.
>
>
>Agreed completely - I think diving in and making mistakes is the way to
>learn. I think reading someone else's code is the worst way to learn. For
>all those giving advice like: 'read what's in the image', how many of those
>actually learned Smalltalk that way? I tried this and found it next to
>useless. Until you get a firm grounding via tutorials and examples, reading
>the base classes makes no sense. Even if I have someone else's code, I learn
>by attempting to formulate my own algorithm, and scrawling some pseudocode.

Not to belabor a point, but if instead of "scrawling some pseudocode" you
actually write in smalltalk pseudocode it will become your design and make
more sense.  For example, one may write in pseudocode:

	if item not selected then redraw.

and code it in smalltalk as

	item notNil ifTrue: [self redraw].

Instead write the pseudocode as

	self itemNotSelected ifTrue: [self redraw].

and define the method #itemNotSelected to do the appropriate thing.

When you use this style your thinking flows right into the code
much easier.  Additionally, what you really end up doing is creating
a more abstract design which is more reuseable.  In the above example
you could redefine #itemNotSelected to use a different representation
and have very little impact on your code.  Whereas, if you had coded
'item notNil' you could end up fixing several methods.


Terry Raymond
Crafted Smalltalk
(401) 846-6573    http://www.craftedsmalltalk.com





More information about the Squeak-dev mailing list