The EROS and KeyKOS operating systems were designed with a number of principles in mind. This article in IEEE Software describes many of those principles. Another one is:

Design object interfaces for programs, not humans.

The design of EROS/KeyKOS encourages developers to structure applications as a set of interacting components or objects. This structuring is facilitated when the interfaces that objects present are program-friendly rather than human-friendly. Some examples:

interface element	human-friendly form	program-friendly form
number	decimal text string	binary integer
file	open dialog window	capability
option selection	command-line options	struct

This principle could also be stated:

Separate functionality from human interface.

This principle seems obvious when you consider that it is easier to write a program to take a program-friendly interface and translate it into a human-friendly interface, than vice-versa, because the translator is a program not a human.

This design principle came naturally to the EROS/KeyKOS designers because we are programmers, not humans. Just kidding! But this principle allowed us to build considerable functionality quickly. In KeyKOS, and in EROS to date, there is rich functionality but precious little human interface, so we were not tempted to think of the human interface first.

Why is this principle so rarely observed in desktop software today? Perhaps one reason is that economic models have not yet emerged to allow an application to be easily composed of components from disparate origins. In other words, how do you make sure you have all the pieces and have paid appropriate license fees to their owners? In KeyKOS we did not get around to worrying much about this. In EROS we encourage free software.

This page was last updated on 28 January 2003.
Copyright (c) 2003 Charles R. Landau