> First off, thank you for your through reply

No prob.

> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?

Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.

> A lot of my confusion about whether it's the object or the representation of the object comes from this level.

I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.

The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.

> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.

Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.

The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.

Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.

For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.

> For a comparison point, during my day job, I write a large amount of Python in Emacs.

Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.

> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.

Yup, Emacs is an image.

> I can call the "help" function on an object

On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.

> to see its documentation or the "dir" function to view all its members and methods.

I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?

> I can load code at run time and patch new members onto classes or objects.

Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.

> Of course, that's the classic Blub programmer paragraph.

Yup, but at least you're aware of that, so you've un-blubbed IMHO.

> At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors.

And multiple IDE's and multiple workspaces, windows all over the place.

> I'm also sure that the Smalltalk documentation is better written than what I usually get from "help".

Actually, honestly, you'll find very little documentation to speak of for most Smalltalk code; Smalltalker's tend to just read the source, it's there, it's simple, the average method length in a typical image last time I looked was about 7-10 lines of code, and you can just create instances of anything on the fly and play with them to see how they work, or find existing running instances and play with them.

> Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.

Yup, but I think you'll understand by the time you read this line based on your Emacs use alone.