Image Based Language

An image-based language is a language in which the primary means of development consists of programmers modifying an (usually in-memory) image of the runtime environment. Typically, the image includes a set of facilities (browsers, editors, at the minimum an interactive shell or ReadEvalPrintLoop) for communication with the programmer; and the programmer can modify/extend these to his heart's content.

Some image-based languages allow the language facilities themselves to be modified; others do not. In many such languages, the line between "language implementation" and "application" is blurred. In many cases, the preferred method of saving one's work is to save the entire image; as opposed to saving a collection of text files containing source code which represent the program.

The canonical example of an ImageBasedLanguage is SmalltalkLanguage. Another example was LambdaMoo.

Advantages and disadvantages of this approach:

• When done right (ie Smalltalk), results in a seamless development environment which is often quite pleasant to work in.

• Integration with a version control system might be difficult.

• Deployment of finished code can be tricky, especially if deployed standalone (decoupled from the development system). Piecemeal deployment of a developed system (upgrading one class/library in a system already in the field) is especially challenging.

• Some ImageBasedLanguages have a reputation of being PinkyAndTheBrainLanguages that don't always "play nice" with the rest of the world.

• Distributed development can be tricky

• The dependence on mysterious eternal undocumented binary bits with, for all we know, no existing matching source code, raises many disturbing issues, not least concerning security. See KenThompson's TuringAwardLecture "ReflectionsOnTrustingTrust". Note, though, that some image-based environments can dump their own code, at least in a useful sense If you mean, dump every last bit in readable form, so that it can be profitably studied, and is complete enough to be used to restart the system (e.g. serialize/deserialize), then yeah, that goes a long way. That's basically what I meant.
  • But see TheLawOfMutatingBinaryImages, which contradicts this in regard to Smalltalk to some extent.

---

Can SQL be considered an "image-based" language? The "image" would be the database. The database can contain code, such as stored procedures, triggers, and views, as well as data. Admittedly, you can't redefine the database's primitives; for example you cannot view or redefine the implementation of the SELECT statement. A database can be used by multiple developers and users at the same time.

SQL is certainly an ImageBasedLanguage.

In some ways a Docker container (see https://www.docker.com/) also "feels" like an image. You can run a shell inside a Docker container, modify the container directly, and save the container as a new image, but the preferred method of developing a Docker container is to write a Dockerfile script which describes how to build the image from "scratch" (typically a pre-existing public image with a Linux system inside, but there is a real image called "scratch" which is genuinely empty).