How does a newbie get past the feeling thay he is trying to
understand an elephant whilst looking through a keyhole?
Dan Shafer
dan at shafermedia.com
Mon May 8 19:47:23 UTC 2006
Maybe this will help someone struggling with this issue. Maybe it won't.
I've been an on-again, off-again Smalltalker for years. I've authored
or co-authored several books on the subject. I've helped design and
write two pretty substantial systems in Smalltalk. I'm not an
engineer by training or discipline but I'm a programming language
junkie with a pretty decent grasp of object-oriented concepts.
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*.
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...." And my fingers would fall back onto
the desk. I'm not kidding about this. It sometimes took me a very
long time to be willing to start coding even when I was sure what I
was doing.
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? 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.
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.
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 starting with a pile of
building materials and building a house. There were some large-
function building blocks and some very small ones, but you took them
from a seemingly infinite pile of those pieces and you fabricated a
house pretty much from scratch, following a blueprint whose level of
detail and sophistication varied dramatically. Programming in
Smalltalk is more like adding a new office or apartment to a
skyscraper whose very building fabric has connectors for 90% of what
you want to do and suitable building supplies to fill in the missing
pieces. If I build a house, I don't have to worry too much about
fitting in to some other scheme (other than rules and regulations,
that is). But if I'm going to create a new office space atop a 3875-
story skyscraper that already has a lot of stuff in place, I'd better
be trying to fit organically into the existing scheme of things and
create symbiotically.
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.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Dan Shafer
"Looking at technology from every angle"
More information about the Squeak-dev
mailing list
|