November 2001

This document contains my rantings on how the DBOS should be designed. I have been following my philosophy from the beginning. It would be interesting to see the impacts my philosophy has on choices and consequently my mistakes.

Semantics is Everything

How you express something is very important. The semantics of a statement can provide additional information in differing contexts. All reasonable contexts must be considered when constructing a statement. A lack of consideration for a context can lead to interpretation error in that context; and we get poor semantics. Facing the risk of error given the plethora of contexts we want to minimize the length of our statements, deferring the interpretation to the context. The reduced length will limit the contexts that can apply and reduce possible interpretation error. Of course, these shorter statements should not negatively impact the expressibility of the underlying language.

Efficient Semantics are Complex Semantics

Generally what I mean is that a system that allows many things to said succinctly must have complex semantics. A simple example is a set of domain specific languages. Each language solves it's problems with a minimum amount of code. As a whole, the combined complexity is greater than any single language. I have included a whole document on this point.

Everything is Transient

Despite the desire to come up with a final design, there will always be new information that can not be handled by that design cleanly. Therefore I never see my designs as final, and furthermore do never put in the effort to do so. The DBOS is a set of standards for manipulating itself, none of these standards are permanent, just a step in the right direction. Some standards could be cleaned up, but it is better to wait for a new standard to replace it.

Complexity is Inevitable

Any system that is meant to do complex things will be complex. Complexity has a common synonym, "bloat". I have heard too many complaints about OS bloat and application bloat. Why do people care? Are the things that are contributing to this bloat really not useful? Certainly much of what makes up bloat is not useful to the person complaining, but certainly is useful to someone: Are bytes so precious that we should not care about another's useful feature? Bloat is inevitable in the creation of a complex system and should not be restrained.

Nothing is Impossible

This is about redefining the problem rather than finding an impossible solution. By finding the true problem, or relaxing inane requirements, solutions (heuristics) that are good-enough can always be found.

Complex Problems do not Exist

It has been my experience that once a proposed solution is coded it's 'incorrectness' becomes apparent. I put incorrectness in quotes because the process of solving a problem is iterative; each iteration solves a little more of the total problem. Each of the these sub-solutions are simple and therefore the whole is simple, albeit time consuming. Of course this philosophy is a state of mind. You could argue that the relative complexity of the problem is the number of iterations you require to solve it. I am saying that anyone can solve any problem.