Questions on Stack Overflow are expected to relate to programming within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

3

I've always thought this "greatest idea in the history of computer science" was one of the reasons Smalltalk is so underused. I like Smalltalk in theory, but the image thing always makes me a little uneasy.
– ChuckApr 6 '09 at 17:24

I feel the same way as Chuck, only I've been into Smalltalk for not even a month, and I don't think I'll do anything "big" in it in order to say how good the idea of images is.
– Andrei Vajna IIApr 6 '09 at 20:34

It would be silly to think image based development is appropriate for every situation - it isn't. When the situation involves a rich domain model, a bit like a simulation, being able to play with and fix the populated domain model on the fly helps keep clients happy.
– igouyApr 6 '09 at 23:33

Its a shame this ones closed as its an interesting way to come at the question of "whats an image". I'll give one good one example though. Zope. Zope uses python, but the code, and data are all stored in a NoSQL type heirachical database. Zope was huge in the 1990s, but fell out of favor because it was pretty alien to the uninitiative and ultimately lost favor to Django, a much more familiar framework. None the less it was for all purposes a monolithic image system that paved the way for modern NoSQLs and adding a few unique features of its own.
– ShayneFeb 13 '18 at 2:22

11 Answers
11

Images are basically memory dumps. Typically a Lisp development system starts a runtime plus an image. The user then makes changes and later can write a new image. Sometimes this is a feature used by the developer, sometimes it's also used during the development of the Lisp system itself.

Many Lisp systems are using 'images'. That's where Smalltalk got it from, possibly - since Lisp had images already long before Smalltalk existed. McCarthy's Lisp 1.5 in the early 60s used images. The knowledge about Lisp implementation techniques was transferred to Xerox. L Peter Deutsch for example worked in the 60s on Lisp implementations - in the early 60s as a young kid he wrote his first Lisp. In the 70s he worked at Xerox and there especially on Smalltalk's virtual machine implementation.

Later in the 70s/80s, the OS on the Lisp Machines were basically Lisp images (often called worlds) (even hierarchical images with incremental delta images). Lisp Machines also store development environment state (example: which code is loaded from where in what version written by whom) in an image, but the MIT variants of the Lisp Machine usually stored the source code itself in files.

Managed source code

If you ask which language uses a similar way to organize and manage source code (i.e. not in files in project directories), then Xerox Interlisp did that. Apple's Dylan did that. Some DB development tools might do that.

I'd add "Unix" is an image based development system. The image is the file system – sadly they just store dead text instead of meaningful objects. Relational DBMs are image based development systems. I agree with the OP that images are amazingly powerful. I think a mistake was thinking of "an" image is an important thing. It should be a replicated cache, like a git repo. Not "all your work", like a word document.
– BenjohnNov 4 '16 at 10:16

Your memory is accurate. I don't think of MUMPS as image-based, but does have a container/alternate-storage-system where data is solely managed by the MUMPS system. APL has workspaces to store code and arrays. I think you could even argue that Forth did some of this with its block-oriented filesystem for code. There were at one time Prolog systems that saved "working memory" as disk images. It used to be common practice, especially when the OS system calls didn't do a good job with compression and memory-management of special data structures, which is why LISP and Smalltalk did it too.
– David WhittenMay 12 '12 at 22:53

I do not know why but the LISP syntax is so hard to read... anyway I will check How common lisp is implemented using images.
– Claudio AcciaresiApr 6 '09 at 17:00

2

I haven't recommended Common Lisp. I've just answered the question.
– steschApr 6 '09 at 17:12

The reason some people find the syntax so hard to read is that there pretty much isn't one. You just write the parse tree as S-expressions. Some people find this lack of structure...disturbing.
– David ThornleyApr 6 '09 at 17:16

I found Smalltalk code hard to read till I started learning the language and understanding that everything reduces to "Object - Message". The same is for Lisp, everything reduces to "(function args)". I used to think the Lisp model is the simplest evere. But now I think Smalltalk's is more natural.
– Andrei Vajna IIApr 6 '09 at 17:22

Yes, I see what you mean, and I Agree, Smalltalk is really close to natural language (at lest from my point of view :))
– Claudio AcciaresiApr 8 '09 at 13:42

If you had 20 programmers working on the same codebase, how does that work? Do they each have their own image, or do they share one?

If you make a code modification that requires a modification of your environment, and someone makes a different modification with similar requirements, can the images be merged (as with Version Control)?

Either developers exchange change sets, i.e. the equivalent of patches, or they use version control tools, which tend to work in a more DVCS-like fashion, and on code entities (classes and methods) rather than files and lines of code: - Envy - Store (Cincom Smalltalk) - Monticello (Squeak, Pharo).
– Damien PolletApr 6 '09 at 17:17

1

For example with Envy/Developer, one programmer could create a new edition of a method, make and accept a series of changes to that method (each accepted change would be recoverable), explicitly name and version a particular edition (other programmers can see the changes) and then publish.
– igouyApr 6 '09 at 23:13

For example with Envy/Developer, although you could see that another programmer had created editions of code you were also working with, in practice you'd probably ignore that and merge with the published version and then publish your merged version.
– igouyApr 6 '09 at 23:16

I happened across this comment which I think gives a flavor of image based development.

'So while I can and do use the JVM for server-side computation, it’s a bit heavy weight for small and simple tasks. Common Lisp’s answer to this problem was an ingenious one. Instead of building programs that you run over and over, it offers an “environment” in which code is iteratively evaluated, so that you actually grow and nurture a burgeoning set of functionality within a long-running VM. I like this model when appropriate, and enjoy it, for example, in Emacs, which I can leave running for days on end while at the same time extending its functionality by writing new functions and customizing variables."

Early BASIC interpreters could be considered image-based, in that they incorporated a rudimentary editor, and retained the source form of a program in memory while the user worked on it, and provided commands like "SAVE" and "LOAD" (or was it "READ"?) to save the whole program to a source file and load it again later.

Single-page applications can be considered as a sort of images for JavaScript+HTML. Single-page application means a [web]-application where all data, code and state are contained in a single HTML document.