The Elements of Operating-System Style
Before we can start discussing specific operating systems, we'll
need an organizing framework for the ways that operating-system
design can affect programming style for good or ill.
Overall, the design and programming styles associated with
different operating systems seem to derive from three different
sources: (a) the intentions of the operating-system designers, (b)
uniformities forced on designs by costs and limitations in the
programming environment, and (c) random cultural drift, early
practices becoming traditional simply because they were there
first.
Even if we take it as given that there is some random cultural
drift in every operating-system community, considering the intentions
of the designers and the costs and limitations of the results does
reveal some interesting patterns that can help us understand the Unix
style better by contrast. We can make the patterns explicit by
analyzing some of the most important ways that operating systems
differ.
What Is the Operating System's Unifying Idea?
Unix has a couple of unifying ideas or metaphors that shape its
APIs and the development style that proceeds from them. The most
important of these are probably the “everything is a
file” model and the pipe metaphor
[20] built on top of it.
In general, development style under any given operating system is
strongly conditioned by the unifying ideas baked into the system by
its designers — they percolate upwards into applications
programming from the models provided by system tools and APIs.
Accordingly, the most basic question to ask in contrasting Unix
with another operating system is: Does it have unifying ideas that
shape its development, and if so how do they differ from
Unix's?
To design the perfect anti-Unix, have no unifying idea at all,
just an incoherent pile of ad-hoc features.
[an error occurred while processing this directive]
