Unix Philosophy

Last updated Feb 9, 2024

Here are some examples:

• Small is beautiful.
• Make each program do one thing well.
• Build a prototype as soon as possible.

The Unix Design Philosophy emphasizes simplicity, modularity, and efficiency. Major tenets include the value of small, focused programs that perform one task well, the importance of prototyping early, and the preference for portability over immediate efficiency. Data should be stored in flat ASCII files for longevity, and software should be leveraged for reusability. Shell scripts amplify this leverage, and programs should avoid monopolizing user attention. Every program is fundamentally a data modifier and should act as a filter.

Minor tenets stress user customization, maintaining a compact operating system kernel, and the tradition of using lowercase for readability. It discourages excessive printing, promotes parallel processing, and values the collective power of smaller programs over monolithic ones. It’s often more practical to aim for solutions that address the majority of needs (90%) rather than striving for perfection. Cost-effective solutions tend to be more widespread than expensive high-quality ones. Lastly, hierarchical thinking is encouraged for uniform task application, though its limitations are acknowledged.

• Small is beautiful. Small things have tremendous advantages over their larger counterparts. Among these is the ability to combine with other small things in unique and useful ways.
• Make each program do one thing well. By focusing on a single task, a program can eliminate much extraneous code that often results in excess overhead, unnecessary complexity, and a lack of flexibility.
• Build a prototype as soon as possible. Most users looking for a new piece of software won’t know what they really want until they see it, so requirements documents are often misleading about the users’ real needs. The Unix design philosophy makes prototyping a central part of the methodology: give the user something, anything, up-front to criticism, and work from there.
• Choose portability over efficiency. If today’s hardware just about runs a program with just about adequate efficiency, tomorrow’s will run it with power to spare. So the developer’s task is to make sure his program will run on that new hardware with minimal effort.
• Store data and configuration info in flat ASCII files. Valuable data will generally out-live any one program, machine, programming language or use. Data is only useful as long as it’s being used, and flat files help ensure that data is usable for the longest possible time. For complex data structures where flat text really isn’t appropriate, use a structured text format like XML instead: you can always strip-out the mark-up to get at the raw data.
• Use software leverage to your advantage. Many programmers have only a superficial understanding of the importance of reusable code modules. Code reuse helps one take advantage of software leverage, a powerful concept that some Unix developers use to create numerous applications in a comparatively short time.
• Use shell scripts to increase leverage and portability. Scripts generate huge leverage - every line of the script can invoke several “proper” programs, each with several thousand lines of code. A programmer who can’t re-use other programs is condemned to re-write them.
• Avoid captive user interfaces. A program that prevents the user from using any other commands for the duration “captures” the user and prevents him from taking advantage of other commands. A program should be usable in many modalities to maximize its usefulness.
• Make every program a filter. The fundamental nature of all software programs is that they can only modify data, never create it. Therefore they should be written to function as filters since they are filters.

• Allow the user to tailor the environment. No single decision will suit all users - so don’t force one upon them. The more tailorable an environment is, the more users can match it to their needs and the more they’ll like it.
• Make operating system kernels small and lightweight. Despite the never-ending push for new features, Unix developers prefer to keep the most central part of the operating system small. They don’t always succeed at this, but this is their goal.
• Use lower case and keep it short. Using the lower case is a tradition in the Unix environment that has persisted long after the reason for doing so (that it’s easier to read text with descenders on a teletype) disappeared.
• Save trees. Data committed to paper is essentially dead. There are good reasons for keeping all text on-line and using powerful tools to manipulate it.
• Silence is golden. A silent command is often more usable, providing the function asked for and nothing more. You can always provide wrappers for people who prefer a more conversational tone. (See  RuleOfSilence, compare with  SilentFailureNoisySuccess)
• Think parallel. Most tasks are composed of sub-tasks which may be attacked in parallel. This also applies to user interactions. Parallelism can save a great deal of time and frustration.
• The sum of the parts is greater than the whole. A large application built from a collection of smaller programs is more flexible and hence more useful than a single large program. The same functional capability may exist in both solutions, but the collection-of-small-programs approach is the more forward-looking of the two.
• Look for the 90% solution. Doing 100% of anything is difficult. Doing only 90% is far more efficient and cost-effective. Handle the 90% and let the 10% fend for themselves - often they’ll handle their own special requirements far better than you would anyway. ( EightyTwentyRule)
• Worse is better. That which is cheap but effective is far more likely to proliferate than that which is high quality and expensive. The PC-compatible world borrowed this idea and made quite a go of it….
• Think hierarchically. Hierarchies allow tasks and attributes to be applied uniformly across nested elements. This is a powerful idea that encourages decomposition and modularity. (Counterview:  LimitsOfHierarchies)

• Implementation simplicity is more important than interface simplicity.
  • Not even JWZ formulated it thus, IIRC. It was “simplicity of implementation instead of simplicity of using code” or something thereabouts. Unix interfaces are not particularly complicated; they just force extra work upon the user.
    • Actually,  RichardGabriel said in his  WorseIsBetter essay “the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.”  http://www.jwz.org/doc/worse-is-better.html
  • I would be interested in seeing an example of this design choice.
    • CeeLanguage, perhaps?  EdIsTheStandardTextEditor might be even more apt. The original shell (pre-Bourne, even) was quite primitive and not especially good as an interactive shell.
    • That misses the mark. The v6 shell was simple, certainly, but it was better than most, perhaps even better than all, other CLIs on small computers at the time (16 bit minicomputers, not larger e.g. 36 bit computers), and in that sense, was neither primitive nor bad as an interactive shell.
    • Well, the Unix filesystem API is “simple” (open, read, write, seek, close, link, unlink, …) but no system call is guaranteed to succeed (not even close(), pun intended) and few are guaranteed to either do something totally or nothing at all.
• Make it run on the cheapest/slowest hardware
  • Doesn’t this conflict with “Choose portability over efficiency” above?
    • Not really, since low-end hardware seems to reliably take over the market after a few iterations. Look at how many high-end systems are x86-based these days, and how few people cared when SGI died and took their shiny Indy boxes with them. For older examples,  DigitalEquipmentCorporation’s MiniComputers were pretty pitiful in 1960, but a decade or so later, Unix (another low-end solution that won big) was able to ride them into a respectably dominant market share. Then DEC itself was killed from below when the x86 machines got interesting…

More on wiki.c2.com/?UnixDesignPhilosophy.

Data Analysis and Batch Processing. Unix Inspired

Origin: X
References: UnixDesignPhilosophy
Created 2023-10-27