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