In this post I’d like to publish my comments on a series of article by Ramin Honary claiming that “Emacs fulfills the UNIX Philosophy”. I consider this an interesting question from a kind of “theoretical” perspective, though probably practically irrelevant, and had previous correspondence with the Author on the matter.

The following contains a (abridged) few comments, notes, issues and suggestions I had sent Ramin before the article was published, most of which rather constitute my own than some objective view on the topic. For that reason I find it appropriate to publish them on my own site:

Emacs is an app platform

I believe we already mentioned the term “app” in our previous correspondence? I would at least add a footnote to clarify the point that had me irritated, that the term “app” had not necessarily imply a restricted, ready-made system where the user has no introspection or creative freedom on his own to mould their computing beyond the coarse, isolated, already available blocks one might find in an “app store”.

So I think it is better to define Emacs not as an editor, but as a Lisp app platform. It can be thought of as analogous to how the World Wide Web is a JavaScript app platform, or Microsoft’s .NET is a C# app platform.

I don’t know much about .NET/C#, but I hesitate to agree with the Javascript analogy. Maybe that should be elaborated on?

Seems like Functional Programming (FP)

In a UNIX Programming Environment, the fundamental unit of code that is a “program” is conceptually equivalent to a “function” in a FP language. The definition of a “program” need not be restricted to code that runs in it’s own process, and that would be a somewhat meaningless constraint to apply.

I might perhaps phrase this differently and rather say that it is an arbitrary restriction from someone considering the Unix philosophy from the specific perspective of a Unix environment (consisting of the kernel, a shell, pipes and the context of all the other traditional Unix programmes).

The point is that within a shell, Emacs appears to be alien, due to the “cultural distance” between the two. Invoicing Emacs functions from a shell is possible and can help illustrate the point, but at least when using something like Bash it is cumbersome. This can be contrasted with a tool like AWK, that in itself is comparable to Emacs as an Elisp interpreter, but is designed in such a way as to “fit in” to the existing culture.

Note that this gap also exists in the opposite direction, but Elisp has managed to bridge it slightly better (e.g. consider something like process-lines) – probably out of necessity considering that the shell remains more popular. But there remains a “translation overhead”, in that shelling-out is rarely idiomatic, seldom preferable to explicitly starting a process.

Of course, one could list several more distinguishing properties of FP than just the above three. Just to name a few: purity, referential transparency, pattern matching, polymorphism, and equational reasoning. But as long as we can agree that the three above points I mentioned are indeed useful and distinguishing properties of FP, it is easier to see the parallels between FP and the UNIX Philosophy.

I believe it would be productive to go into this point in more detail, as it is both crucial to your argument and especially prone to being misunderstood by someone who hasn’t considered this point of view before.

Perhaps one should distinguish between “lesser FP” (the core concepts you describe here) and “greater FP” (that a proper functional language like Haskell, Idris, OCaml, …) would satisfy. This is also important as Lisp is also not traditionally a “greater FP” language. After all, idiomatic Elisp is more often imperative than pure and functional – it has to be as the “side effect” of Elisp is the text editor and the user environment itself.

But yes, ultimately Lisp centres on the evaluation of expressions, rather than the execution of commands.

Lisp does FP better than UNIX shell programming

It just so happens that Emacs is one of the oldest Lisp implementations still in wide-spread use that was originally implemented for UNIX OS and it’s clones. Decades of evolution have made Emacs one of the most practical means of integrating Lisp-style FP within the UNIX Programming Environment.

This is a good point, and I might add two factors that contribute to this:

1. Elisp is not a standardised language specification (like Scheme or CL), so it was always easier to adapt the “vocabulary” and add new functionality.
2. Elisp by virtue of being the Lisp for GNU Emacs, the Emacs implementation for Unix and Unix-like systems, never found itself in the abstract position that other Lisp insisted on, in not wanting to accept the current dominance of Unix-style operating systems, and preferring to remain OS-generic (e.g. consider CL’s default file handling).

The parallel histories of UNIX and Lisp

In time, John McCarthy would come to work at CSAIL, and would bring Lisp with him to do symbolic computing and artificial intelligence, along with other AI founders like Peter Norvig and Marvin Minsky.

I might be misreading something here, but Peter Norvig was 8 years old in 1964. And from what I gather on his Wikipedia page is was never directly related to the MIT.

But by the time McCarthy started working at CSAIL, Kernighan and Ritchie were no longer working on Multics, they had moved on to invent the C programming language, which would then be used to develop UNIX.

Uh, that is not the account I am familiar with. Kernighan usually denies being involved with the creation of Unix. That is usually attributed to Ken Thompson, and it was initially written in PDP-8 assembler. Only with the PDP-11 in 1971 was there the move to rewrite it in a system-independent language Ken and Dennis created to this end, which ended up becoming C.

This is a good, recent overview by Ken Thompson himself: https://www.youtube.com/watch?v=EY6q5dv_B-o.

and MIT professor Richard M. Stallman talks about how he had used these UNIX computers while developing the first pieces of GNU software in the early 1980s.

Not sure if Stallman was ever a professor. He might have been offered the position, but to my recollection his position at the MIT was always as a kind of research assistant/systems programmer/administrator.

So Emacs was one of the earliest interactive Lisp REPLs ever programmed for the UNIX OS.

Not quite true, I think that Franz Lisp (https://en.wikipedia.org/wiki/Franz_Lisp) predates it

The UNIX people were not guided by Lambda Calculus, and without the solid mathematical foundations that McCarthy used for Lisp, UNIX shell programming turned out to not be anywhere near as elegant as Lisp.

I would be careful about that claim, as it is known that McCarthy didn’t understand the lambda calculus completely when designing Lisp, but rather just reused the name for anonymous functions. See https://www.cs.kent.ac.uk/people/staff/dat/tfp12/tfp12.pdf, page 6 (“[…] At the time he invented LISP, McCarthy was aware of (Church 1941) but had not studied it. The theoretical model behind LISP was Kleene’s theory of first order recursive functions”).

Unfortunately, without the Lambda Calculus as a guide, the UNIX Philosophy turned out to be a misguided, incomplete description of functional programming.

I would expect a phrase like this to gather some critique from unfavourable readers. You appear to be putting the cart in front of the horse, by assuming Unix was aspiring towards functional programming, instead of just realising a less general version of the same idea.

And it becomes even more difficult when you consider this post by Paul Graham, in which he claims that Doug McIlroy was present as a presentation by John McCarthy introduced Lisp.

Therefore Emacs does actually follow the tenets of the UNIX Philosophy, in some ways, even better than the UNIX Programming Environment does so itself.

This is also an inference that people might take issue with, since you are proving something for the more general (weaker) interpretation of the “UNIX Philosophy”, but then you deduce a claim regarding the specific “UNIX Philosophy” that doesn’t directly follow, since the UNIX Philosophy is embedded in the specific technical factors and limitation that were discussed above.

I believe that the safer but equally satisfying claim, that Emacs does not contradict the spirit and values of the UNIX Philosophy, would be preferable. Since unless someone is dedicated to the concrete implementations (in which case they cannot be convinced of the point regarding Emacs to begin with), they should be able to recognise that the principles of simplicity, modularity and re-usability are given when using Emacs/Elisp, as soon as they let go of the arbitrary fixation on what a program is and how it is implemented (an operating system process executing a file).

Yes, exactly. Or you could just use Emacs as your shell.

I would also remind the reader of what a shell is: A “generic” program that sits between the user and the kernel Or it wraps the kernel, just like a shell would wrap a crab. Emacs is a shell in a substantial sense, even if you don’t “chsh” it, since it can take user commands and “translate” them into system calls to the operating system so that stuff actually happens.

This also ties into the initial point, and on why the term “apps” irks me. It appears you didn’t use it to construct any argument. Considering Emacs as a shell that constitutes an interactive programming environment, you can regard Emacs as any other classical Unix shell that just has more built-in and in-shell functionality and a stronger type system (or any type system at all, albeit dynamical, as it is probably more adequate for an interactive environment).