Emacs fulfills the UNIX Philosophy

This is part 6 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

I still find that people seem resistant to the idea that Emacs is actually a good example of the UNIX Philosophy in practice. I even have difficulty convincing people that the UNIX Philosophy is in any way similar to the practical application of FP. Maybe this is the result of the editor holy wars phenomenon, and that I am a known Emacs zealot. Over the years, I have heard various objections to my thesis:

• If you don't like Bash, UNIX lets you use whatever shell you want. — Sure, and you can use Emacs as as shell.

• UNIX lets you run a program written in any language. — Emacs can execute OS processes just as well as a shell language can.

• Without the UNIX Philosophy, there are no composable programs. This is denying the antecedant, a logical falacy.

• So is Microsoft Windows UNIX now? Whether MS Windows follows the UNIX philosophy is not a counter argument to anything I have said.

You don't have to use Bash to script the UNIX programming environment. If Bash is such a bad FP language, you could use a more modern shell like Fish or Nushell.

Yes, exactly. Or you could just use Emacs as your shell. Must your shell be exclusively a REPL in order for programs to be composable? You could try running a program, capturing it's output in a buffer, then running another program as a filter on that buffer. This is an alternative method to appending one program after another to a shell pipeline.

It is also possible, even practical, to substitute the Emacs executable for the Bash executable as your login shell.

chsh -s /usr/bin/emacs;

In the UNIX Programming Environment, a function (program) can be written in any language at all, it is a homogeneous execution environment. The language is often binary code that has been compiled from languages like C, C++, Rust, or Go. But programs written in Bash, AWK, Perl, and Python are also designed to be used in shell pipelines.

Again, Emacs can be used as a shell. It can compose many programs written in many different languages as well as Bash can.

In any programming language, functions are often all written in the same language. This leads to better performance because code execution remains in a single runtime system, without process forking, for greater extents of the program. But when composing functions or programs written in different languages, any shell language must fork a process.

If one is arguing that programs should be composed at the OS level, rather than the interpreter level, this is less than convincing. As a thought experiment, if you had a fundamentally different, non-UNIX computing platform, perhaps something like the Symbolics Lisp Machines, running a Bash interpreter, would Bash still be the better way to compose programs into a pipeline? Does the OS or computer hardware determine what is the best language to use for composing programs into a pipeline?

But the UNIX Philosophy is the reason why we have efficient forking of child processes, being able to compose processes into pipelines of programs all sharing streams of bytes. Without the UNIX Philosophy, program composition would not be possible.

This is a case of denying the antecedant, a logical falacy. Composabile functions can exist absent an ethos of composability.

True, the POSIX standard does define APIs for forking child processes, and for handling byte streams between the parent and child process. And true, it is because of these POSIX APIs that program pipelines (function composition) are possible across all the many OSs that implement these APIs. But function composition can and does exists outside of POSIX. The old Symbolics Lisp Machines and the Xerox Star come to mind as examples of non-POSIX systems that still provided an environment of small, tool-like, composable programs written in Lisp. On the Xerox Star, both InterLisp and SmallTalk programming environments were implemented, and also introduced the idea of copy and paste, drag and drop, and object-oriented message passing, as ways of graphically composing programs.

Programming environments that have small, tool-like, composable, programs can exist indepndent of the UNIX Philosophy.

By your logic, Microsoft's Windows and DOS operating systems follow the UNIX philosophy too. MS Windows implements most of the POSIX API, MS-DOS has had shell pipes since 1983. PowerShell has built-in support for JSON as a data interchange format.

This is irrelevant to my point. Most of the GNU userland, including Emacs and Bash, have been ported to Windows. You can use all of the GNU tools on a Windows OS kernel. Even without the GNU userland, many applications written for Windows nowadays follow the UNIX Philosophy in their design. The vast majority of Windows software does not follow the UNIX philosophy, that doesn't mean the UNIX philosophy is categorically absent from MS Windows. Likewise, popular GUI-only tools on Linux do not make Linux less UNIX-like.

Maybe people who say this confuse the UNIX Philosophy with the GNU Free Software Philosophy, since the GNU Free Software Philosophy is an important ethos of Linux, but not UNIX.

The UNIX Philosophy says absolutely nothing about the philosophy of Free Software. The original UNIX OS was proprietary software, and the AT&T corporation enforced licensing relentlessly. The frustration with proprietary licensing for software on UNIX, and more specifically, the proprietary (non-UNIX) OS software for the PDP-10 minicomputer, is precisely what prompted Richard M. Stallman to start writing clones of all of the UNIX software under a project called GNU (an acronym for GNU is Not UNIX), protected by a share-alike software license agreement called the GPL. Then this further led to the free software political movement. These GNU project clones of the original UNIX software are still in use today in nearly every single Linux distribution.

GNU software, as a clone of UNIX, does indeed follow the UNIX Philosophy, even though it explicitly is not UNIX.

By all means, let's continue defining our programs to be more like composable functions in a FP language. But we need not restrict ourselves to only using programs that can be composed with shell pipes. We can incorporate a FP language such as Emacs Lisp into our workflow, and include composable Lisp programs into our box of tools that do one thing, and do it well. I often recommend people try using Emacs as your shell in place of Bash, it is likely that having access to both Lisp functions in the Emacs Lisp environment, and shell programs like grep in the UNIX Programming Environment, will help you to discover new ways of composing the myriad simple programming tools on your computer into interesting solutions for various computing problems.

That said, my larger goal here was not really to convince anyone to use Emacs, just that Emacs is a fine example of the UNIX Philosophy at work, and not the polar opposite of it. Emacs does in fact meet the requirements defined by the UNIX Philosophy if you are willing to grant that Emacs is not a text editor, but a Lisp interpreter. Emacs does one thing, and does it well: it runs interactive Lisp programs.

Most importantly, I hope I presented enough evidence to convince you that the UNIX Philosophy is really about FP, the idea that functions are programs, and functions should be simple and composable. Emacs Lisp is a functional programming language, and so Emacs commands written in Lisp following the principles of FP are a good way to write programs that do one thing and do it well.