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