1972 to 1980What the system actually was
It is remembered as a language and it was an environment. The running system contained the program, the editor, the compiler, the debugger and the interface, all as objects of the same kind, all modifiable while running.
There was no separate act of building. Changing a method took effect at once, including in code currently executing, and the debugger was not a viewer but a place where a halted program could be edited and resumed.
The image
The whole world was saved as a snapshot: memory, objects, open windows, the state of everything. Restarting resumed exactly where it had been.
That is a genuinely different model of what a program is. There is no source of truth outside the running system, and no moment at which a text becomes a process. The text is a view onto a live object.
1980s onwardsWhat was taken from it
A great deal, and not the part that mattered most to its authors. The overlapping windows, the menus and the pointing device went everywhere. The idea of objects sending messages went everywhere, in a narrower form. The separation of a model from its display went into every user interface framework written since.
The integrated environment went too, as a category: the modern development environment is a descendant, with the crucial difference that it edits files.
What was not taken
The image. Everything else survived translation to a world of source files, and the image could not, because a snapshot of a running world cannot be compared with another snapshot.
You cannot diff it, review it, merge two people's work in it, or reconstruct how it got into its current state. It is a photograph of a result with no record of the process.
Why that was decisive
The entry on version control in this document is the other half of this one. Once teams larger than a room became normal, the ability to compare two states, merge them and review a change stopped being convenient and became the organising principle of how software is made.
Text files are a poor representation of a program and an excellent representation of a change. The environment that lost was better at the first thing and incapable of the second, and the industry chose the second without ever framing it as a choice.
1980sWhat else worked against it
Honesty requires the unglamorous reasons too. The system needed hardware most people did not have, was commercially licensed at prices aimed at institutions, and arrived as a complete world that could not be adopted incrementally.
A technology that must be taken whole competes badly against one that can be taken in pieces, and almost everything it invented was available in pieces from somebody else within a decade.
2010s onwardsWhat is coming back
The live parts have been returning without the name. Notebooks that keep a running session alongside the text. Reloading changed code into a running program. Browser tools where the inspector edits the live document. Interactive sessions as the normal way to explore a library.
Each of those is the old model readmitted in a bounded form, with files still holding the truth. Which is the settlement: liveness during the work, text as the record.
What an image does to deployment
A further problem, less romantic than the diffing one and probably as decisive. If the artefact is a snapshot of a running world, then shipping it means shipping accumulated state, and reproducing it means replaying every action that produced it.
There is no build from source, because there is no source in the sense the word acquired. Two installations that should be identical have no way to prove that they are, and an installation that has drifted cannot be reset except by starting from a distributed snapshot and doing the work again.
The part that was genuinely better
Debugging. A halted program in that environment is an object you can inspect, modify and resume, with the whole system available to ask questions of. Nothing since has matched it in ordinary use, and most practitioners have never seen it.
What passes for a debugger in most modern workflows is a printed line, which is a considerable regression dressed as pragmatism.
present dayThe cost of the settlement
Worth naming, since this entry is otherwise a story about the right side winning. Editing a file and waiting to see the result is a slower loop than changing a live object, and the industry has spent four decades rebuilding fractions of that immediacy with watchers, reloaders and incremental compilers.
The environment that lost had it in 1976 without any of that machinery, and the reason is not that its authors were cleverer but that they were not trying to satisfy a process built around comparing texts.
What we cannot verify
The system, its releases and its capabilities are documented, and implementations descended from it can still be run. Explanations of why it did not spread are contested and usually reflect the interests of whoever is offering them. Claims about intent by any individual are recollection, much of it given decades later in interviews.
In short
- It was an environment before it was a language: everything editable while running.
- The image saved the whole world, so there was no source of truth outside it.
- The windows, the objects and the model-view separation were all taken.
- The image was not, because a snapshot cannot be compared with another snapshot.
- Text is a poor representation of a program and an excellent one of a change.
- Liveness is returning in bounded forms, with files still holding the truth.