Smalltalk weblog

I've started a weblog detailing my (past and) recent experiences with
Smalltalk and Dolphin. The blog is directed toward my own goals, but I
thought others here may find it interesting. Likewise, while I'm still
learning Smalltalk, I'm sure that much of the jargon I'm using it
incorrect and I'd appreciate any corrections people may have.

http://learningtotalk.blogspot.com/

Thanks!

Jeff M.

Jeff,

> I've started a weblog detailing my (past and) recent experiences with
> Smalltalk and Dolphin. The blog is directed toward my own goals, but I
> thought others here may find it interesting. Likewise, while I'm still
> learning Smalltalk, I'm sure that much of the jargon I'm using it
> incorrect and I'd appreciate any corrections people may have.

I just took a look at your first (hopefully, of many) blog entry.
Great! I'm glad you've had an aha moment with Smalltalk after all this
time, especially as you had it with Dolphin.

Actually, this sort of article is extremely important for other
beginners to see. I remember thinking to myself that Smalltalk syntax
was really weird and defining globals in dictionaries must surely be
overkill (and tens of other similar complaints) before eventually
getting familiar enough to take the language on board.  It is difficult
now to remember all of the barriers that I perceived as a beginner,
which is what makes your thoughts so useful to seasoned Smalltalkers.

My story used to be on the Dolphin wiki, which is no longer
functioning, so you may not have seen it. Back in 1994 I was technical
director at a company called Intuitive Systems and we were searching
for a replacement for our ageing 4GL, Intuitive Solution. We'd been
aware of Smalltalk since the company started in 1984 and indeed I had
created an Objective-C style language and engine for our original
product which I derived from reading the Smalltalk-80 Blue Book.
However, I could never quite "grok" Smalltalk itself.  By 1994 the
performance of Smalltalk on PCs was now adequate, with the release of
the first Pentium processors, so we decided to take another look at
Smalltalk as a potential way forward for our 4GL business.  Blair had
recently joined the company so I asked him to dive into Smalltalk by
getting down and writing some real code -- in this case an object
relational mapping layer using Visual Smalltalk Enterprise.  He hadn't
seen much of Smalltalk before.

After the first day, Blair responded with "this Smalltalk, it's
bollocks" ("bollocks" being English slang for balls/rubbish). I
persuaded him to carry on and after one week he noted that there was
some quite good stuff in this new language.  After two weeks he was so
hooked on the system that he was able to proclaim, "this Smalltalk,
it's THE bollocks" (which is English slang for fantastic/great). So it
had taken a smart guy two weeks of solid work to actually appreciate
why Smalltalk is so good.  Given that "appreciation curve", it's no
wonder that we are struggling to coax new programmers into the fold.
Note that, while Blair was doing his experimentation, I still didn't
know Smalltalk myself.  It was only after Blair's epiphany that I
decided to get down and learn the language and appreciate it myself!

You mention the fact in your blog that you are from a games programming
background.  One thing you might like to try, because it amazed me when
I did it, is to dynamically perform some Refactoring on your game code
while the game is being played.  You may know that about a year ago I
created a 2-D arcade-style game in Dolphin (www.dalektron.org) with my
(then) nine-year-old son, James. I used to set James playing the game
and he would come up with ideas as he would actually going around
shooting the baddies.  We had a two screen system and he was playing
full-screen DirectX on one monitor and I was able to modify the code
dynamically in the Dolphin browsers on the other. Even after all these
years with Smalltalk I just found it cool that I could completely
refactor and change the class hierarchy or the method names immediately
without even having to pause or stop the game.  I suspect that this
sort of demonstration would get a great "wow" response if you showed it
to any C++ game developers.

Anyway, thanks for sharing your blog with us, let's hope it attracts
more people into giving Smalltalk a whirl.

--
Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Jeff M. wrote:
> I've started a weblog...
Hi Jeff
 Looks good. I am thinking of posting things especially toward the
beginner. A few personal favorite hints that you  may or may not  have
discovered.

 1) I put '  self show  '  either in the 'Class Comment' work area  of
a Shell derived class so I can quickly launch 'test' by clicking the
Class Comment tab, putting the cursor on the end of the line, right
clicking, and 'evaluate it' which beats clicking the succession of menu
to fine the 'view | default view'. Not a big deal but a real time
saver.

Sometime when I'm debugging with one particular method, I will add
'MyClass new inspect' in a comment in that method, with opening
quotation mark, on one line, MyClass new inspect, on the second line,
and closing quotation mark on the third line, which allows me to
"evaluate it"  for an instance of the class and quickly see how things
are going, especially initialization. I sometimes do this with 'self
halt' to get the interactive debugger.

 2) You can do a butch of quick code execution in any workspace (places
where you can edit) then when satisfied, put the code in a 'method' to
incorporate into your classes as they develop. I can remember learning
how a Dictionary class worked by interactively trying things out
message out, such as 'at:put:' and inspecting the results.

3) I have not done a lot of Forth, but recall how one could redefine a
previous word
by simply re-using the word, and leaving the previous definition in
place and the interpreter would execute only the most recent word. I do
a similar thing can be done in Smalltalk. For example, if I'm working
on a method, say >>recalculate, which will be used by 'self
recalculate' somewhere, and I start wondering about alternative
implementations, or factoring, I keep that copy around for reference by
renaming it >>recalculateGOOD, simply by appending 'GOOD', then
'accepting it'. Then I can go back and modify >>recalculate contents
knowing I have a good copy of it around that I can get back by browsing
to >>recalculateGOOD, editing it to >>recalculate with 4 backspaces,
then 'accepting' to start all over if needed. Versions that don't work
exactly as I want can be relabel, as >>recalculateBAD1, etc. 'accept',
and kept around for as long as desired.

I found this to be quicker than finding looking for where the sender
is, and changing. For instance, instead of  changing 'self recalculate'
to 'self recalculate1' , I leave 'self recalculate' in place.

Good luck, have fun
ACG

Hi Jeff,

Nice post!

I hope you keep posting ... I am interested in your Smalltalk progress,
as well as your progress with DirectX and your game. I have played
around with DirectX in Dolphin and a game kit (Truevision I think it
was called), but never did much. Probably like many programmers, I
dream of one day being in a position to do a good game :)

I remember having a Smalltalk "moment" ... strangely enough it was
while reading a book based around Scheme (Structure and Interpretation
of Computer Programs). The first line of that book is "We are about to
study the idea of a computation process" ... and it certainly got me
thinking about processes.

At the time I was working in a Scheme environment, but I still spent
more time playing around with the examples in Smalltalk. My moment was
in the debugger when I realized I was looking at an object that was the
computation process, and I could see the objects making the computation
happen.

It was like suddenly seeing a level down ... a level that kind of
reached up to the objects I was familiar with (ie Person, Dog etc) ,
and changed their state and moved in and out of the code I had written
... and the cool thing was, the objects one level down, were
effectively the "equals" to mine. It was like going from a 2D world to
3D world!

Attempting an example ... instead of evaluating 'ShellView
allSubclasses', select it (without the quotes) and press F11 (or
right-click/debug).

In the debugger that opens, "Step Into" a couple of times. Then click
the "Visual Object Finder" (magnifying glass icon), and click on one of
the lines in the stack list (top-left listView).

This should open an inspector on one of the stackFrame objects that is
part of your computation. (FWIW: The frame objects would be optimized
away if there was no debugger on the process ... but, in my mind, they
are still always there).

You can also see the process itself. Click on the "Tools" menu, then
click on "Process Monitor". Find the process in the list with the name
"Main" and state "debug". (FWIW: the Main/running process is the
process doing the debugging (it starts/stops the Main/debug process
when stepping) and is handling the user input/Windows messages at the
moment).

Right-click on the Main/debug process in the "Process Monitor" and
click on "Inspect". (Switch the Inspector to the "Instance Variable"
tab to see more).

This gives you another viewpoint on your process. Keep stepping in the
debugger and you can watch your computation evolve.

One last thing ... not only can you evaluate 'ShellView allSubclasses',
you are free to change its behavior. You could, if you want, change
Behavior>>allSubclasses to answer ^#() ... although this is definitely
not a good idea :)

By compiling in Behavior>>allSubclasses ^#(), it means that all
processes that create a frame object with the Behavior>>allSubclasses
compiledMethod, will get back an empty array ... that will cause
problems for your image (although it is always fun to try these
things!)

Much safer is to just modify your process so that your allSubclasses
(frame) returns #(). To do this, In the debugger, right-click on the
'ShellView class(Behavior)>>allSubclasses' frame, then click
"Return...", enter '#()' (without the quotes) and click OK. Bingo ...
'ShellView allSubclasses' just returned #()!

"Return..." and "Restart" are great for really manipulating and
exploring your process as it moves through your objects. You really get
to explore/modify not just the objects themselves, but their
interaction ... the process object(s). I would imagine that would be
helpful for game programming ... IMO it is always fun ... a game
itself!

I don't think words and examples can do "moments" justice ... I hope I
have not mangled things for you, but at the least ... keeping peeling
off the layers ... there are more objects waiting for you :)

Steve

Jeff M. wrote:
> I've started a weblog detailing my (past and) recent experiences with
> Smalltalk and Dolphin.

Nice read - keep it up. I think something that touches on the experience
of learning Smalltalk is particularly useful, as Smalltalk is a fairly
closed community, and there are some initial barriers to being
comfortable with the language - I remember bouncing off it the first
time I looked at it.

Some of your blog entry is taken from your posts to
comp.lang.smalltalk.dolphin, which I almost replied to at the time, but
was ultimately too lazy to bother. This gives me my second chance.

You talk about your initial reservations about OO, and the sight of
people writing absurdly overextended and overabstracted inheritance
hierachies because they think they should - and I like the phrase "I've
C++'ed myself into a corner again." I just wanted to say though that I
think overuse of inheritance isn't a sign of a problem with OO itself -
it's a natural stage of learning OO, which people come out the other
side of with a more balanced attitude.

I remember when I was trying to teach myself OO I kept trying to build
inheritance hierachies all the time - because that's what I was supposed
to do. Then I got a job at a company that was doing Objective-C (on its
original home of NeXTStep, not on Apple) and got to see people writing
OO style - and saw how inheritance was only part of the picture.

In more recent times, I've tutored Smalltalk in a University
introduction to OO unit for a couple of years, and while looking over
some past projects it struck me that the projects with stupid amounts of
subclassing and inheritance were from the *brighter* students - the
smart curious ones who'd got the idea, got all excited, and wanted to
take their shiny new hammer and treat everything in the whole world like
it was a nail. I'm assuming they eventually got over it.

It's interesting to hear of you coming to Smalltalk from a console game
background. The first 5 years of my working life (back when dinosaurs
walked the earth and the oceans were full of trilobites) were writing
games in 8 bit assembler for the Sinclair Spectrum and the very first
version of the Nintendo - the old NES. Probably because of this, I've
never shaken off the idea that the only respectable use for computers is
to write games - though I've ended up doing less exciting things. I've
always meant to try writing some games in Smalltalk, to see if it would
be as productive, flexible and fun as I hope it would be. Perhaps I should.

> Jeff M.



                     cheers,



                            Steve