As Simple As Possible, butNoSimpler

Table of Contents

Speaking of Complexity
The Three Sources of Complexity
Tradeoffs between Interface and Implementation Complexity
Essential, Optional, and Accidental Complexity
Mapping Complexity
When Simplicity Is Not Enough
A Tale of Five Editors
The Right Size for an Editor
Identifying the Complexity Problems
Compromise Doesn't Work
Is Emacs an Argument against the Unix Tradition?
The Right Size of Software

Everything should be made as simple as possible, but no simpler.

-- Albert Einstein

At the end of Chapter1, we summarized the Unix philosophy as “Keep It Simple, Stupid!” Throughout the Design section, one of the continuing themes has been the importance of keeping designs and implementations as simple as possible. But what is “as simple as possible”? How do you tell?

We've held off on addressing this question until now because understanding simplicity is complicated. It needs some of the ideas we developed earlier in the Design section, especially in Chapter4 and Chapter11, as background.

The large questions in this chapter are central preoccupations of the Unix tradition, some of them motivating holy wars that have simmered for decades. This chapter starts from established Unix practice and vocabulary, then goes a bit further beyond it than we do in the rest of the book. We don't try to develop simple answers to these questions, because there aren't any — but we can hope that you will walk away with better conceptual tools for developing your own answers.