Chapter�燙omplexity

As Simple As Possible, but燦o燬impler

Table of Contents

广告：个人专属 VPN，独立 IP，无限流量，多机房切换，还可以屏蔽广告和恶意软件，每月最低仅 5 美元

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

ed
vi
Sam
Emacs
Wily

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

At the end of Chapter�a>, 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 Chapter�a> and Chapter�/a>, 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.

 

 

 

Prev  Up Next

Throughput vs. Latency  Home 燬peaking of Complexity