Emacs fulfills the UNIX Philosophy

Part 2: What is the UNIX philosophy?

This is part 2 of a 6-part series of articles defining what the UNIX philosophy is, what Emacs is, and discussing whether Emacs fulfills the UNIX philosophy.

0. Introduction
1. Emacs is an app platform
2. What is the UNIX philosophy
3. Seems like Functional Programming
4. Lisp does FP better than UNIX shell programming
5. The parallel histories of UNIX and Lisp
6. Response to common criticisms

In part 1 of this series I dispell the myth that Emacs is a bloated text editor that does everything. I declare that Emacs is really a Lisp interpreer, and therefore it does just one thing and does it well: it runs Lisp programs, so in this way, Emacs does fulfill the UNIX Philosophy.

But is this really a satisfactory argument? It might sound like Emacs technically follows the UNIX Philosophy, but does not really follow the spirit of the philosophy. So in the rest of this series, I want to really examine how the UNIX Philosophy is defined, what some of the key principles of UNIX are, and whether using Emacs allows you to really follow the principles of the UNIX Philosophy.

What the authorities say

Several notable software engineers, most of whom actually worked on the UNIX project at Bell Labs, have spoken on the subject:

• Doug McIlroy in the foreward to original manual for the UNIX Time-Sharing System in 1978.

• Brian Kernighan and Rob Pike's indispensible text book, The UNIX Programming Environment in 1984.

• Peter H. Salus who wrote A Quarter Century of UNIX in 1994.

• and Eric S. Raymond's texbook The Art of UNIX Programming in 2003.

Of course, each person has their own way of defining what the UNIX Philosophy is. Reading through all of their opinions on what the UNIX Philosophy is, I can find three main points that all definitions have in common:

1. Programs should be simple, minimal, elegant, general, modular, composable tools. Each program is a tool that does just one thing, and does it well, and tools should be designed to compose to solve larger, more specific problems.

2. Programs are composable if they focus on transforming or filtering data, and data should usually be both human readable and machine readable text whenever possible. CSV and S-Expressions are good ways to interchange data. Nowadays JSON is likely to be the most popular data interchange format that is both human and machine readable.

3. Programs should encourage task automation through experimentation. It is implied that using a Read-Eval-Print Loop (REPL) to experiment with executing programs, and being able to immediately see the results of program execution, is an important tenet of the UNIX Philosophy.

So it is clear that the UNIX Philosophy is describing a way of thinking about how to design and use programs.

This is usually explained with an adage:

Every program does just one thing, and does it well.

— Doug McIlroy

To elaborate on this further:

Because the philosophy is based on the relationships between programs, we must devote most of the space to discussions about the individual tools, but throughout run the themes of combining programs and of using programs to build programs. To use the UNIX system and its components well, you must understand not only how to use the programs, but also how they fit into the environment.

— Kernighan & Pike, preface to The UNIX Programming Environment

The UNIX philosophy is to think of programs as tools. Consider what properties of tools in the operating system are desirable. Eric S. Raymond describes tools with all of the words simple, small, transparent, robust, modular, readable, flexible, and composable. Other people use words like minimal, elegant, beautiful, and general. The point that the UNIX Philosophers seem to be making is that it should be easy to reason about the behavior of a program as easily as you can reason about the behavior of a hammer or screwdriver. And you should be able to easily reason about ways to use programs together in pipelines to transform data.

I whole-heartedly agree that this is a virtuous property for any piece of software to have. After all, humans have evolved a powerful innate skill for using tools. So building systems of interconnected tools comes naturally to us, and our computational tools should work the same. I strongly prefer programs to work like tools, or perhaps components similar to electronic circuits — in fact, theoretically any software can be implemented as an digital electronic circuit and vice-versa. There is something deeply satisfying to me about the idea of software components wired together like electrical circuitry, or plumbing in a hydraulic system.

Conclusions

Now we know what the authors of UNIX think, and we have seen their authoritative definition of the UNIX philosophy is, as well as the opinion of other experts like Eric Raymond and Peter Salus. My own definition of the UNIX Philosophy is a reconciliation of all of the opinions of these authorities, which is the idea that every program is an elegant tool to be used in combination with others. UNIX programs should be designed and used as such. In the next article in this series, I talk about how UNIX relates to the priniciples of functional programming, and Lisp (e.g. Emacs Lisp) in particular. I will argue that this notion of a program according to the UNIX school of thought, is similar to the notion of a function according to the functional programming paradigm.