|
A fascinating point of view from Chris Uppal on
comp.lang.smalltalk.dolphin: groups.google.com/group/comp.lang.smalltalk.dolphin/msg/75719c339369ba5e
Damon wrote: > I bought the book Smalltalk Companion, by Ted Bracht, to
see if I can > pick up Smalltalk. I’ve programmed in Java for
several years, and I > think I have a decent grasp of OOP issues. >
[…] > Missing though are insights that I seek to translate the
concepts that > I learned in developing in the file-based language of
Java with its > edit/compile/test iterative development process to the
image-based > interactive development process of Smalltalk.
Welcome aboard!
I made the Great Leap Forward from Java to (Dolphin) Smalltalk a few years ago
and I think I can still remember how it felt. My motives were not too unlike
yours -- curiosity about what was claimed to be a better way of working, more
than anything. What I got out of it wasn't quite what I'd expected. I was
hoping to find better tools, what I found was a different way of thinking about
OO.
You've already had a couple of fairly direct answers to your specific
questions. I'm going to try to take a step back and talk a little about the new
way of thinking. I'll try to relate it to your questions as I witter on, but
the connections may seem (be) rather indirect.
BTW, this is all -- obviously -- only my own opinion. Other Smalltalkers might
disagree with much, or even all, of what I want to say.
The "image" is the *central* concept of Smalltalk. In comparison, nothing else
is very important. (I'm aware that there are Smalltalk dialects that don't have
images, but I -- personally -- can't see the point.). If you are like me, then
you are currently thinking of a big difference between Smalltalk and Java being
that Java stores code in files, whereas Smalltalk keeps it in the image. That's
sort of true, and I'll get back to it, but, for a minute, just forget about
code, it's not important (really!). What matters is *objects*.
The image is the place where the objects live. Technically, the image is a
garbage-collected heap that can be saved to file, and later restored, thus
saving and resuming the state of a computation. *Technically* that's true, but
it isn't at all a helpful way to think about it. A more organic metaphor works
much better. I think of the image as a deep, murky, pond where objects move
around in the depths like fish. It's an important part of the metaphor that the
objects are *independent* of me. Even if I designed and wrote the classes, once
an object has been created it has an independent existence. I can talk to it, I
can ask it to perform operations, but it is separate from me. In a sense it is
"my" object, but it is only "mine" in the same way that a pet, or a rose bush,
or a table, could be "mine".
The image is where the objects live. Not the code, the objects. We'll get back
to the code in due course, but not yet. The Smalltalk environment is just a
place where you can talk to objects; no more, no less. Oh, sure its got class
browsers, debuggers, editors, etc, but that's all tinsel. What matters is that
it is a place where you can interact with the objects.
I'll get back to the "tinsel" later too, but for now, I want to talk about the
one part of the environment that isn't just a productivity aid: the workspaces.
Workspaces are the medium through which you talk to objects. You *can* describe
workspaces as "containing snippets of code" which you execute, but IMO that's
exactly the wrong way to think of it. A better picture (slightly
tongue-in-cheek) is as a kind of singles bar, where you can meet objects, talk
to them, check them out, get to know them. Each workspace has a number of
objects that are (temporarily) living there; they are the values of the
variables in the workspace. In most cases they'll die when you close the
workspace, but until you do they'll survive and you can talk to them. I keep
some workspaces hanging around for days if they contain objects that are
important for what I'm doing. The way you "talk" is by sending messages written
in the Smalltalk programming language, but that's almost incidental. The
important thing is that you are communicating with them using an interactive
text-based medium, like using an IRC channel.
I very much like that picture. A workspace is like an IRC channel for talking
to objects. One difference is that the other users of a real IRC channel don't
usually die when you sign-off (at least I don't think so, I admit that I've
never actually used IRC).
(BTW, you can save the *text* of the workspace in a .ST file -- it's actually
saved as RTF -- but that just saving a transcript of the conversation. If you
re-opened the text in a different workspace window then you'd see the text but
the objects wouldn't be behind it. Using cut-and-paste from one workspace to
another has the same effect and can be a good way of killing unwanted objects
without loosing the record of what was said.)
Another way of interacting with objects is to use the Inspector(s). They give
you a much more nuts-and-bolts, low-level, view of the object -- a more
intimate view, if you like. I, personally, don't think that the Smalltalk world
has yet woken up to what inspectors *could* be, but the current implementations
(like "flipper" in Dolphin) do at least allow you to see inside the objects.
An image will contain many objects, some long lived (living, perhaps, for
decades), most very short lived indeed. Some will be simple or trivial, like
Strings and Points. Others will have complicated internal structures, and/or
complicated behaviour. But they are all objects, and they all live in the
image, and you talk to them in workspaces.
Classes are one particularly interesting kind of object. Remember I'm *still*
not talking about code (that comes later), I'm talking about the objects called
classes. Just like any other objects, you can invite them to join you in a
workspace:
class := String.
and then you can use the magical Smalltalk object-oriented IRC to talk to them:
class name. "--> #String"
class allSubclasses size. "--> 3"
and so on. So classes are objects, and they live in the image.
Since Smalltalk is a programming environment with GUI features, there's nothing
more natural once we've reached the point where we have an image full of
objects, than to start writing tools that allow us to interact with the objects
in more structured/convenient ways. Workspaces and Inspectors are fine for the
basics, but we'll soon want better tools that allow us to see the relationships
between objects (or some subset of objects -- the classes for instance), or
what messages they understand. Maybe we'll want to be able to modify their
behaviour, or create new kinds of objects. That's exactly what the IDE
provides. The class browsers, etc, are merely a collection of tools for talking
to objects. They are useful, even highly desirable, but ultimately dispensable
because we could talk to the objects without them, anyway.
But now it's time to get to the subject of code. The progression I've taken,
starting at objects, then the important tools, then classes, then more tools,
and finally code, really does represent a progression from the most important
to the least. In this way of thinking the code is the least important part of
programming in Smalltalk. (Of course, I'm schizoid about this, I don't
*really* think that the code is the least important part -- just muck with my
code's formatting and watch me explode -- but on the other hand, I really *do*
think that the objects are more important.)
Code is how we tell objects how to behave. It's text in the Smalltalk
programming language. We're programmers so we care about code; when we wrote
the tools for looking at objects, we naturally designed the tools so that we
could also see the associated source code. For instance our special tool for
looking at classes (the class hierarchy browser) allows us to see the source of
the methods, to change the source and recompile, etc. That's natural for us as
programmers. If we weren't programmers then we'd want different tools, and we'd
be interested in talking to different objects. Such systems, built for
non-programmers, are called "applications", but they are still just
Smalltalk -- tools for talking to objects that live in an image. (A big
difference is that the "image" of an application is typically not persistent,
unlike the image of the IDE).
Back to code. Granted that the most important thing is the objects and how they
behave, we still do care about the code. We want to organise it, back it up,
put it under source code control, etc. A class is an object that lives in the
image, but the source code *for* that class is something else. For all sorts of
reasons, we want to keep that outside the image. The way that Dolphin organises
source-code is via Packages. A package is a collection of the source code for
classes and methods (and a few other things too, which don't matter here) that
is kept outside the image in one or more files. You can load the package into
the image, which will create an actual Package object, and class objects
corresponding to the source-code. Or you can "uninstall" the package, which
really means killing the Package object and the Class objects.
So a package is just a way of collecting related source-code together. Some
Smalltalks go further and associate namespaces with packages. Dolphin doesn't
(and I'm not at all sure that I think that's a bad thing). You can load the
same package into different images, in which case you'll have duplicate
versions of the class objects living in both images. If you do that then you'll
want to be careful not to make changes to the classes in one image and not the
other, because then the package file cannot reflect the state of both images.
The package mechanism is relatively simple; it could be improved, but I find it
adequate for my needs. Package files are text files, you can edit them with vi,
or notepad, or whatever. Occasionally I do that if I want to make particularly
sweeping changes to the source. Of course, if you do that then you have to
install the changed version into the image before it'll do anything useful.
Notice how very different this way of thinking is from the way that even the
best Java IDEs encourage you to think. When I started out in Smalltalk I was
thinking of the IDE as if it was a Java IDE. I though of it as a tool that
allowed me to write code, and had features to allow me to browse and test the
code. After a year or so I realised that I'd turned the picture upside down
completely, and in the process had revised my conception of what
Object-Oriented programming is all about. As a Java (or C++) programmer I had
pretty much thought my .java (and .cpp) files *were* the classes, and I thought
that creating classes was what programming was *about*. I now think of the
objects as being the important thing, and the classes as very secondary, hardly
more than an implementation detail.
I *feel* that that has made me a better programmer. Of course it's not possible
to know for sure, but if it has, then it all comes down to Smalltalk's
workspaces...
(A couple of asides for seasoned Smallalkers, if any are still reading:
Was Dolphin the first Smalltalk to have workspaces that kept the values of
variables rather than throwing them away after each evaluation ? VW used to
discard them and I think VASt still does. Squeak keeps the values, but I don't
know how long that's been true. Anyway, whichever implementation it was that
introduced the idea can -- I think -- claim to be the first *truly*
object-oriented Smalltalk. Presumably also the first truly object-oriented IDE
of any kind.
Writing this has made me focus on the unease that I still feel with
programming-in-the-debugger. I was already a bit suspicious that it might
encourage a (crypto-)topdown approach to decomposition. I'm now starting to
wonder whether it also is part of a "code-centric" way of thinking, rather than
the "object-centric" mindset that I think Smalltalk *should* foster.)
BTW. One book on Smalltalk that I heartily recommend, especially if Ted
Bracht's "teach-by-example" approach isn't right for you, is Chammond Liu's
book, "Smalltalk Objects, and Design". It's the best book on Smalltalk that
I've ever read (although it's not Dolphin-specific), and in fact I'd say it's
the best book on OO that I've ever read too.
Oh well. Once again, this has been a longer post than I'd intended. I don't
know if anything I've said has made any sense to you, or has seemed even
slightly relevant. I've had fun writing it anyway...
-- chris
|
