The model refers to a component module of the program by its unique name, independently of the location in the file system where its bits are stored. The development of a program can be described by a collection of models, one for each stage in the development; certain models define releases. ... In 1983 a system is specified by text which is stored in files. This provides modularity in the physical representation: a file can name other files instead of literally including their text. in Cedar, these files hold the text of Cedar modules or system models. This representation is convenient for users to manipulate; it allows sharing of identical objects, and facilitates separate compilation. Unless care is taken, however, the integrity of the system will be lost, since the contents of the named files may change. To prevent this, we abstract files into named objects, which are simply pieces of text. We require that names be unique and objects be immutable. By this we mean that: • Each object has a unique name, never used for any other object. The name is stored as part of the object, so there is no doubt about whether a particular collection of bits is the object with a given name. A name is made unique by appending a unique identifier to a human-sensible string. • The contents of an object never change once the object is created. The object may be erased, in which case the contents are no longer accessible. If the file system does not guarantee immutability, it can be ensured by using a suitable checksum as the unique identifier of the object. These rules ensure that a name can be used instead of the text of an object without any loss of integrity, in the sense that either the entire text of a system will be correctly assembled, or the lack of some object will be detected. What happens when a new version V2 of an object is created? In this view, such a version is a new object. Any model M1 which refers to the old object V1 continues to do so. However, it is possible to create a new model M2 which is identical to M1 except that every reference to V1 is replaced by a reference to V2; this operation is called Notice and is discussed further in § 3. In this way, the notion that objects are immutable is reconciled with the fact of evolution.

I read some of these and I feel like all of those people at PARC must just be perpetually disappointed in what the rest of us have come up with since.

sounds pretty rad

The Modeller provides an interactive interface for ordinary incremental program development. When used interactively, the role of the Modeller is similar to that of an incremental compiler: it tries to do as little work as it can as quickly as possible in order to produce a runnable system. To do this, it keeps track incrementally of as much information as possible about the objects in the active models. For example, consider the following scenario. Assume a model already exists, say BTree.model, and the user wants to change one module to fix a bug. Earlier, she has started with BTree.model as the current model. She uses the editor to make a change to BTreeImpl.cedar!(Jan 14, 1983, 14:44:09). When the user finishes editing the module and creates a new version BTreeImpl.cedar!(April 1, 1983, 9:22:12),, the editor notifies the Modeller by calling its Notice procedure, indicating that BTreelmpl.cedar!(April 1, 1983, 9:22:12) has been produced from BTreelmpl.cedar!(Jan 14, 1983, 14:44:09). If the latter is referenced by the current model, the Modeller notices the new version and updates BTree.model!(Jan 14, 1983, 14:44:11) to produce BTree.model!(April 1, 1983, 9:22:20), which refers to the new version. The user may edit and change more files. When she wants to make a runnable version of her system, she issues another command to the Modeller, which then compiles everything in correct order and (if there are no errors) produces a binary file. A more complex scenario involves the parallel development of the same system by two programmers. Suppose both start with a system described by the model M0, and end up with different models M1 and M2. They may wish to make a new version M3 which merges their changes. The Modeller can provide help for this common case as follows: If one programmer has added, deleted or changed some object not changed by the other, the Modeller will add, delete, or change that object in a merged model. If both programmers have changed the same object in different ways, the Modeller cannot know which version to prefer and will either explore the changed objects recursively, or ask the user for help.

paper is here: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/32-OrganizingSoftware.pdf

also found a video demonstrating everything that's pretty cool: https://www.youtube.com/watch?v=z_dt7NG38V4

apparently the system described was Eric Schmidt's PhD work

Found another one to evaluate: https://www.getapid.com

The typical formula here is test lib + http lib. There isn't a reason for those to be bundled.