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
|