Nice post Dan,

> My early experiences with Smalltalk had two fearful faces to them.

> One was the notion that I was not creating a simple program which, if
> it broke, didn't do any damage elsewhere in the universe. Rather, I
> was <insert appropriate scary overture music> *modifying THE image*.

In this case, the image appears to have led to this nervous psyche. 
Other systems don't have a live environment for trying and learning. 
Instead, you start with a blank text editor into which type a program
and subsequently feed to the compiler or interpreter.  These systems
are so closed off there's little or no chance of any danger, is that
right?

Now, I suppose this could be done with Smalltalk too, but its so ironic
that a primary benefit of the environment is *learning* it through live
experimentation and live program development.  I don't know if this
will help but, "Go ahead, its ok."  :)  As you now know, any changes
you make only modify YOUR image and only in memory (until you save). 
So you won't do much damage elsewhere in the universe, so go ahead,
explore!  Once you let go of the fear, I think you will enjoy working
in an image immensely.

> It was kind of like correcting God. I used to pause, my fingers
> poised over the keyboard, as I overrode some method or subclassed a
> builtin class and think, "I'm about to modify the known Smalltalk
> universe. If I screw this up...." 

Please pardon the blasphemy but, in your image, YOU are god.  That's
the attitude adjustment needed for people to take control of their own
software destiny.  The mainstream sw industry counters this by
constantly pummelling the marketing tecnobabble, it actually works in
intimidating people and they become afraid just like you did.

Adding a subclass will never cause any problem.  The new subclass is
your "blank slate" you can feel safe to go crazy.

> The other source of fear derived, for me, from the experience that
> said that it was hard to do basic, simple stuff in Smalltalk that
> would have been a cake-walk in Basic or Pascal, the other languages
> with which I was pretty familiar when I began my Smalltalk
> meanderings (which are far too random to qualify as a journey). Just
> an example. I remember one day thinking I'd write the Basic program
> that was sort of just after "Hello World". It printed out the numbers
> from 1 to 10 alongside their square and cube. Trivial, right? 

Well, I think "familiar" is the key word here, because this is indeed a
cakewalk in Smalltalk too:

  "print it"
  String streamContents:
	[ : stream |
	(1 to: 10) collect:
		[ : n |
		stream cr.
		1 to: 3 do: 
			[ : exp | 
			stream 
				tab; 
				print: (n raisedTo: exp) ] ] ]


Coding time:  2 minutes.  I doubt I could do it in Pascal in < 10
minutes though.  It's just familiarity, thats all.

> Five
> minutes after I opened and installed Basic, I had it working. Pascal
> took longer but that was because the install took longer and I had to
> learn about compilation. I could not get it to run in Smalltalk/V to
> save my gluteus maximus. I can't now remember all the gyrations I
> went through before I finally threw up my hands and asked for help.

When looking at the simple code above, what do you think is the reason
it eluded you so?
 
> But even after that, I remember a lot of times in which I'd spend
> hours poring over the source for various classes and methods that
> seemed like they might do what I wanted to do if only I could wrestle
> them to the ground, finally locate what I needed and then write two
> or three lines of code in a new method that just worked the first
> time exactly as I intended. But the code-shopping phase of
> programming always seemed like it took too long and I believed it
> took too long because I was incompetent somehow. Why? Because always
> before Smalltalk, productivity was measured in lines of code per hour
> or day. In Smalltalk, the real hard-core coders seemed to be the guys
> who wrote the *fewest* new lines of code per day because they figured
> out how to hook into what already worked.

Code-shopping is no different than looking up in the Pascal manual
isn't it?  Except you can be certain the code is up to date, the manual
may not be..  Also, the code can actually be tried and watch it happen
in the debugger:

  SomeMysteriousClass new halt someMysteriousMethod

> I finally created this analogy. At least I think I created it. Maybe
> someone else had it before me but I didn't read it. Writing a program
> in every language except Smalltalk is like ...

Well, this simply sounds like intimidation by the image again.  Once
you create your own subclass and feel completely free to go crazy, you
can just build your house, right?

> Like all analogies, this one breaks at various points, but it does
> draw one to a single and helpful inevitable conclusion. If you want
> to master Smalltalk, spend your first days, weeks and/or months
> (YMMV) studying and understanding the key components of the class
> library. Then go design and write your new apartment of office. It
> will be much less painful, even though it will seem to take a lot
> longer at first.

I add that "studying" does not have to be reading every class of every
method.  Instead, studying should mean do programming exercises that
force you to "query the database" of code (classes and methods) to
find, experiment and assemble them in the live environment.  This
learning "by doing" should have much more lasting impact than reading
the Pascal manual cover to cover.

Regards,
  Chris