Editing Smalltalk (section)

==Image-based persistence==
Most popular programming systems separate static program code (in the form of [[Class (computer programming)|class definition]]s, functions or procedures) from dynamic, or [[Run time (program lifecycle phase)|run time]], [[program state]] (such as objects or other forms of program data). They load program code when a program starts, and any prior program state must be recreated explicitly from configuration files or other data sources. Any settings the program (and programmer) does not explicitly save must be set up again for each restart. A traditional program also loses much useful document information each time a program saves a file, quits, and reloads. This loses details such as undo history or cursor position. Image based systems don't force losing all that just because a computer is turned off, or an OS updates.

Many Smalltalk systems, however, do not differentiate between program data (objects) and code (classes). In fact, classes are objects. Thus, most Smalltalk systems store the entire program state (including both Class and non-Class objects) in an [[system image|image]] file. The image can then be loaded by the Smalltalk [[virtual machine]] to restore a Smalltalk-like system to a prior state.<ref>{{cite web|title=Image-Based Persistence|url=http://book.seaside.st/book/advanced/persistency/image-based-persistency|work=book.seaside.st|access-date=17 December 2013}}</ref> This was inspired by FLEX, a language created by [[Alan Kay]] and described in his M.Sc. thesis.<ref>{{cite journal|last=Kay|first=Allen|title=FLEX – A flexible extendable language|journal=University of Utah MSC Thesis|year=1968|url=http://www.mprove.de/diplom/gui/kay68.html}}</ref>

Smalltalk images are similar to (restartable) [[core dump]]s and can provide the same functionality as core dumps, such as delayed or remote debugging with full access to the program state at the time of error.<ref>{{cite web|last=Fowler|first=Martin|title=Memory Image|url=http://martinfowler.com/bliki/MemoryImage.html|work=martinfowler.com|access-date=17 December 2013 |archive-url=https://web.archive.org/web/20111007113152/http://martinfowler.com/bliki/MemoryImage.html |archive-date=2011-10-07}}</ref>

Other languages that model application code as a form of data, such as [[Lisp (programming language)|Lisp]], often use image-based persistence as well (see [[EMACS]], for example). This method of persistence is powerful for rapid development because all the development information (e.g. parse trees of the program) is saved which facilitates debugging.

However, it also has serious drawbacks{{citation needed|date=December 2022}} as a true persistence mechanism. For one thing, developers may often{{citation needed|date=December 2022}} want to hide implementation details and not make them available in a run time environment. For reasons of legality and maintenance, allowing anyone to modify a program at run time inevitably{{citation needed|date=December 2022}} introduces complexity and potential errors that would not be possible with a compiled system that exposes no source code in the run time environment. Also, while the persistence mechanism is easy to use, it lacks the true persistence abilities needed for most multi-user systems.{{citation needed|date=December 2022}}  The most obvious is the ability to do transactions with multiple users accessing the same database in parallel.{{citation needed|date=December 2022}}