> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. Yes it does. > So I'm not acting dir

> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. Yes it does. > So I'm not acting directly on the object, but a representation of the object. No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save. You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime. Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system. In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger. Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server. Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site. Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control. If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger. A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code. A Smalltalk image is a running object database, not a transactional one, you don't generally want to use it for persistence, however, you can and this is fantastic when prototyping. You can write the entire UI using the image as the database and put off the persistence decision until your app is shaken out and you know what you really want to do. I can just hang an OrderedCollection off my class and use it as the database. I could then query it like so: Customer db select: [:e | e name = 'Joe' and: [ e age > 3 ]]. Hugely helpful when prototyping to be able to simply avoid the persistence issue.