What is a Smalltalk "image"?

In almost every other language (apart from ABAP as far as I have been told by some senior SAP developers), you have a clear separation:

• Code you are working on which defines logic
• State of the program you are running
• database, generally things you need as input for your code

In Smalltalk, all of this can be - note can - in the image. In theory, you can deploy a Smalltalk application in a loaded image which brings all the data and logic and runs the application at startup. In practice, as far as my experience goes, you tend not to do that for reasons.

If you stay inside the image, you have everything available at your disposal, for good or ill. Classes are objects, methods are objects, so you can actually do things like add a

self halt

in a method, run some code which calls this method, change the method while it is being executed, recompile it and have the code continue. You can also do wonderful things like passing method names as string to a method and then performing the argument without having this visible in code anywhere. Both things are very good for learning and trying out. Not so good for production code or maintaining producion code.

The thing I was struggling with in the beginning was that for instance for UI creation, you create a window in the Smalltalk image which is then created "a second time" by the OS, with window handle and everything. Of course, you can save the window with the Smalltalk image, it will also open up again (normally), but what happens internally is that there is a list of windows (i.e. all the UI components) which have been saved with the image in their Smalltalk state. During Image Startup, there is a process that iterates over this list and asks the OS to recreate all of them. In theory, you can do this for everything the OS offers: file handles, resource handles, ports and so on In practice, you probably dont want to do that. The companies I worked at had nice beginner tutorials of code to run before saving your image in order not to get into trouble when restarting the next day.

Ideally, you could combine a Smalltalk image concept with peristence and just store all your objects in a real database. I do not have the overview whether any Smalltalk dialect has done this, however.