Emacs fulfills the UNIX Philosophy

Unpopular opinion: actually, Emacs does fulfill the tenets of the UNIX philosophy. In this 6-part series, I'd like to define what the UNIX philosophy is, and whether Emacs fulfills this philosophy. The UNIX philosophy, in brief is the idea that every program does one thing, and does it well. Does Emacs, with it's multiple built-in Email clients, IRC client, web browser, terminal emulators, software development tools, and games (like Tetris), even fit this definition? It depends on how you define Emacs, that is, whether you think of it as a text editor with too many extensions, or whether you think of Emacs as a general purpose Lisp programming language with hundreds of useful libraries and applications.

In brief:

Although this introductory article alone might be more than enough exposition to convince you of my thesis, here is a summary of the entire series of articles:

1. Emacs does not have extensions, it has apps

I argue that Emacs is an app platform, not a text editor. Many of us have heard the old joke that Emacs is an operating system that lacks a good editor. I have heard many people complain that Emacs has extensions that allow it to do everything, including web browsing and e-mail, and that this violates the UNIX philosophy of every program does one thing well becuase Emacs is one program that tries to do absolutely everything. This is a misconception. In actual fact, Emacs is a programming language and runtime. So it does do just one thing well: it runs interactive Lisp programs. And Emacs extensions are actually applications written in Lisp.

(Read full article)

2. How I define the UNIX Philosophy

So suppose we agree that Emacs is a Lisp app platform. Maybe this is just a technicality. Does Emacs really fulfill the spirit of the UNIX Philosophy? When people actually use Emacs, are they practicing the ethos of UNIX?

In this article, I try to settle on a clearer definition of The UNIX Philosophy. As a starting point, the Wikipedia article on this topic has a pretty comprehensive listing of the various experts who have all spoken on the UNIX Philosophy throughout history: Brian Kernighan, Doug McIlroy, Robert Pike, Peter Salus, Eric Raymond, and others. Actually reading the work of these experts, it is hard to find a single comprehensive definition, but they all seem to agree on the following points:

1. Programs are minimalist tools/components used to construct solutions to problems. Each program should do one thing, and do it well.

2. Programs are composable transformations over data, and the output of a program should be in a human readable and machine readable textual format.

3. Programs should help users come up with their own ways to automate tasks, and should make it easy to experiment with task automation and software development in an interactive environment. Implied is the use of a Read-Eval-Print Loop (REPL) where you can quickly experiment with running a program and seeing results immediately.

(Read full article)

3. The UNIX Philosophy is a misguided formulation of FP

This is really the crux of my argument, that the UNIX Philosophy is really just a misguided, or perhaps incomplete formulation of the principles of functional programming (FP). If you consider that a UNIX program is conceptually equivalent to a FP function, the idea that every program does one thing, and does it well, is another way of expressing the principle that FP functions should be pure, orthogonal, general, and elegant. Most of the the principles of the UNIX Philosophy, at least by my above definition of it, are either in agreement with FP, or are a natural consequence of FP.

(Read full article)

4. Emacs Lisp is a FP language, Bash is not

In day-to-day usage, the Bourne family of programming languages, usually Bash, is used to compose programs together into pipelines, such as with the pipe | operator. Though Bash does allow for some functional programming techniques, it is not a proper FP language, it only provides a few of the features of FP. To the extent that the UNIX Philosophy is really about functional programming, Lisp languages like Emacs fulfill the promise of the UNIX philosophy perhaps even better than UNIX does. An interactive Lisp programming environment such as Emacs provides a proper FP language for general, day-to-day use on UNIX systems.

There was not much, if any, collaboration between the UNIX people and the Lisp people. Unlike Lisp, UNIX was developed without the mathematics of Lambda Calculus as a guide, so I would argue that the UNIX Bourne shell scripting language is really just a naive implementation of a FP language.

(Read full article)

5. UNIX and Lisp have a parallel history

I present an overview of the history of Lisp and the history of UNIX. Though both Lisp and UNIX have roots in the MIT CSAIL laboratory, I conclude that both were developed independently; Lisp preceded UNIX, UNIX did not borrow any ideas from Lisp.

Both Lisp and UNIX emerged with the invention of time sharing systems. The technological advancements of time sharing systems, and the command line interface (CLI) were both novel technologies at this time, and efficient use of the CLI is what underlies both the UNIX Philosophy, and the early Lisp programming techniques that were developed around the Read-Eval-Print Loop (REPL). Emacs was among the first Lisp implementations on UNIX.

Lisp was the first functional programming (FP) language. It was developed at MIT in 1958 on the IBM 704 mainframe computer, was based on the Lambda Calculus of mathematician Alonzo Church, and so it had a more rigorous mathematical foundation than UNIX.

(Read full article)

6. A reply to common criticisms

There are criticisms that I commonly hear when discussing with peers why Emacs actually fulfills the tenets of the UNIX Philosophy. I to address these criticisms in this article.

(Read full article)

One final note

Since I am talking about the UNIX philosophy, I will use the term UNIX in the generic sense to refer to all UNIX-like operating systems collectively, as this discussion also applies to BSD, Linux, Minix, and several other distinct operating systems. Emacs, Bash, and the GNU userland suite have been ported to nearly all such operating systems.

Also, I will write UNIX in all caps, consistent with the excerpts from the book The UNIX Programming Environment.

References

The following is a list of reference material that provide the source of facts that are presented throughout this series:

1. McCarthy, John. Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I. Massachusetts Institute of Technology. April 1960.

2. McCarthy, John. A History of Lisp. Artificial Intelligence Laboratory, Stanford University. 12 February 1979.

3. Ritchie, Dennis M. The Evolution of the Unix Time-sharing System. Bell Laboratories, 1984.

4. Kernighan, Brian W., Pike, Rob. The UNIX Programming Environment. Bell Laboratories, Prentice Hall, Inc. 1984.

Further reading

• Xah Lee, Unix Pipe as Functional Language where he talks about UNIX pipes as function composition. He also points out an interview with Alfred Aho, co-developer of the AWK programming language, who says he thinks of the UNIX shell language as a prototypical functional language.

• Richard P. Gabriel, Lisp: Good News, Bad News, How to Win Big — a well-circulated essay/rant from the year 1991 about why Lisp had lost to UNIX and the C programming language, in spite of both providing useful interactive programming environments, and in spite of the fact that Lisp was clearly the better FP language. He argues that the worse is better principle, the ad-hoc approach to software design, gets useful software to market faster than well-engineered systems, which is one reason why UNIX won and Lisp lost. I will add that nowadays, it seems that Haskell has a similar problem in comparison to languages like Python and JavaScript.

• Philip Kaludercic, Unix Considered Harmful — also goes into depth about the history of UNIX, and warns us to be cautious about taking the UNIX Philosophy as a point of faith. He suggests that being trapped in such a dogmatic view has contributed to a culture of layering hack upon hack to fix problems inherent in system design, which happens when we think of our dogma as unassailable. When caught in this trap, rather than re-asses our dogma, we instead try to work around obvious flaws that we would be tempted to dismiss as implementation details.

• In Steven Levy's 2010 book, Hackers: Heros of the computer revolution, all of part 1 of this book, chapters 1 through 7, tell the human side of the story of the people at the MIT laboratory where Lisp was developed. Many of the stories revolve around the very same PDP-1 and PDP-6 computers on which the first ever Lisp REPL was developed. Although the story is not about Lisp or the REPL, the story paints a picture of the people who were there when Lisp was invented, and what the culture there was like at the time. Part 4 goes into depth about Richard M. Stallman and what led him to develop Emacs, GNU, and the free software movement.

• Derek Taylor's video, Is the Unix Philosophy Still Important? (YouTube link) touches on these issues and makes many of the same arguments as I do in this article, but without comparing UNIX to Lisp the way I do. He also comes to the same conclusions as in Philp Kaludercic's article (listed above) about how the UNIX Philosophy should not be followed dogmatically.