Smalltalk: Swimming with the fish

> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.

> Yes it does.

Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: 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?

A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.

If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.

Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.

Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.

Yes and no, respectively.

Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.

...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.

> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.

And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.

When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.