The Nature of the Unix Philosophy
In the computing industry, especially among unix community, we often hear that there's a “Unix Philosophy”. In this essay, i dissect the nature and characterization of such “unix philosophy”, as have been described by Rob Pike, Ken Thompson, and Richard P Gabriel, and in recent years by Eric Raymond.
Quote from Wikipedia [ Unix philosophy ] [ https://en.wikipedia.org/wiki/Unix_philosophy ]:
This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. (Doug McIlroy, the inventor of Unix pipes. [[McIlroy78] The Bell System Technical Journal. Bell Laboratories. M. D. McIlroy, E. N. Pinson, and B. A. Tague. “Unix Time-Sharing System Forward”. 1978. 57 (6, part 2). p. 1902.])
Eric S. Raymond, in his book The Art of Unix Programming, summarizes the Unix philosophy as the widely-used KISS Principle of “Keep it Simple, Stupid.”
In 1994 Mike Gancarz (a member of the team that designed the X Window System), … which sums it up in 9 paramount precepts:
- Small is beautiful.
- Make each program do one thing well.
- Build a prototype as soon as possible.
- Choose portability over efficiency.
- Store data in flat text files.
There is no one definite set of principles that is the so-called “unix philosophy”, but rather, it consistent of various slogans developed over the decades by unix programers that purport to describe the way unix is supposed to have been designed. The characteristics include: “keep it simple”, “make it fast”, “keep it small”, “make it work on 99% of cases, but generality and correctness are less important”, “diversity rules”, “User interface is not important, raw power is good”, “everything should be a file”, “architecture is less important than immediate workability”. Often, these are expressed by chantable slogans that exhibits juvenile humor, such as “small is beautiful”, “KISS (Keep It Simple, Stupid)”.
Suppose, we take a team of student programers to produce a large software system. When the software is done, give it to software critics to analyze and come up with some principles that characterize its design decisions, without disclosing the nature of the programers. The characterization of such software, will more or less fit the descriptions of the “Unix Philosophy” as described in different ways by various unix celebrities.
For example, it would focus on implementation simplicity as opposed to interface simplicity. It will not be consistent in user interface, but exhibits rawness. It would be correct only for most cases, as opposed to mathematically correct or general. It would employ simplistic data structures and formats such as text-files with rows of lines and space separated columns, as opposed to a structured system or binary format that requires a spec. It would be speedy, but less on scalability. It would consists of many small programs, as opposed to one large system with inter-dependent components. It would be easy to patch and port, but difficult to upgrade its structure or adapt entirely new assumptions.
The essence of this theory is that when a software is produced for real world use, it is necessary that it works in some acceptable way, otherwise the software will be continuously debugged and refined. A software system written by a bunch of student or otherwise under-educated programers, but refined long enough for acceptably practical, real world use, will necessarily develop characteristics that is known as the Unix Philosophy.
Do Unix Tools Do One Thing Well?
Unix philosophy says “small is beautiful” and “do one thing well”, but vast majority of unix commands are not beautiful and doesn't do one thing well. For example, grep supports “-r” option, while it really should be just “grep” + “find”. The command “find” is supposed to be a do-one-thing-well command for feeding multiple files to other do-one-thing-well commands. Yet, “find” itself needs “xarg” in confused combination with its
-exec. Such examples happens everywhere in unix. Unix shells is another example. It began with Bourne shell “sh”, then several tried to fix its shortcoming: bash, and the abomination tcsh. In trying to fix the whole shell bag, came the turd perl. For some detail, see: Unix Pipe as Functional Language
This joke summarize unix well at the time: UNIX Philosophy, Fast Food the UNIX way .
See also: The Rise of “Worse is Better” By Richard P Gabriel. At http://dreamsongs.com/RiseOfWorseIsBetter.html