> I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL.

This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code.

However, it's more common to find image-based development in other Lisp dialects. In the case of Common Lisp, for example, have a look at this[0] paper on the SBCL bootstrap process.

> And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.

Right. Perhaps an example would help clear up what I mean: Say you have an application in some Smalltalk environment, but you want to bring that application up in some other Smalltalk environment (on another platform, for example). All of your code is stored within image A for the original environment, and you have a fresh image B for the other environment. How do you reproduce image A for the new environment starting with image B? If your source code is stored in files, you can easily enough just load those files into the new environment.

On the other hand, I really don't understand what kind of benefits you gain by doing all of your programming in a live environment. I always felt the same way about Lisp's REPL: the interactive interpreter is handy for quickly testing out some code for sure, but I wouldn't want to write my entire application in an interactive interpreter. Why? Because if my sources are represented in plain text files, I can use any number of specialized tools to query and process them. This is the kind of thing people mean when they say things like "Unix is my IDE", and why I am the most productive with Vim open next to a shell prompt and a REPL.

> It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.

It seems that this would solve some of the issues I raised, especially the ability to download into other images. The last time I played with Squeak, there wasn't any git bridge (in fact, there may not have been any git whatsoever... it was quite some time ago), and any builtin version control was pretty awkward and limited.

> You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.

Yes, I am thinking in terms of files. I was trying to make the point that using files gives the programmer far more flexibility in organization, which I see as an advantage compared to using an image. Furthermore, most of the IDEs I've used offer package/class/method browsers on top of files, giving the best of both worlds. Take Eclipse for example: its navigation pane displays a hierarchy of packages, classes, and methods -- it's effectively the same as using the Smalltalk class browser, but the underlying storage is based on a file hierarchy which has been processed by the IDE.

> An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.

I don't believe that one bit, especially considering that there is a variety of tools available for processing text files beyond just a text editor (and, of course, any text editor worth its weight in bits can interface with external programs).

[0]: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf