Some things manage to be simple on the outside even though complicated on the inside. Perhaps the complication buys efficiency by using a sophisticated algorithm. The external specifications of the Pentium are scarcely more complex than that of the 80386, yet the internal complexity is several times as much. Compilers have moderately simple external specs that belie internal complex optimizations.

Today users of ordinary systems must too often cope with imperfect abstractions. An egregious example is the Code Manager Tool which manages the source files of a multi person development project. It presents the developer with an attractive graphical view of the state and history of the project’s code. There are, however, occasions when it throws up its hands and admits defeat. It seems to be saying this is too complicated for me, you figure it out! (Imagine a compiler saying that this expression is too complex: you code it!) At this point it seems that the user is supposed to know even more than the Tool builders. Having insulated the developer from the details so well, so long, the developer’s skills at running the underlying SCCS have probably atrophied. (To the Tool’s credit, many users have never had to learn SCCS, until now!) By the time the developer has sorted out the mysteries, including undoing the damage that he does as he operates under atrophied SCCS reflexes, he may as well never have used the Tool.

This is not entirely the Tool builder’s fault. In a well designed system such a tool can maintain exclusive access to the files and directories of files that constitute the tool’s internal state. The tool can also use more certain techniques than file dates to detect changes to files. With these advantages the tool can take on more complete responsibility for the state of the world. In conventional systems the tool cannot exclude other programs from mucking with its internal state which means that it must cope somehow with internal states that it finds contradictory. It does this by invoking the developer. In effect successive waves of developers must relearn how to work around the glitches of the tool. There is no hope of “fixing” the tool in conventional systems.

To imagine a system that addresses such problems requires some observations: Current “Make”, compilers, loaders, etc. are designed to have access to directories and files in some guise to do their job. The tool can export an interface that behaves as a directory, yielding objects that behave as files, if we want to retain legacy code. Another observation is that we need objects (including state!) whose duration spans system power down and up. Such objects need to be efficient, for they are at the core of what the computer is bought to do!