Unpopular opinion: actually, Emacs does fulfill the tenets of the UNIX philosophy

This is the overview article for a 6-part series of articles about the UNIX Philosophy, Emacs, and why I think Emacs actually does fulfill *The UNIX Philosophy,* maybe even better than UNIX itself does. I hope to counter that old joke about Emacs being an operating system (it is actually an app platform, not an OS), or the idea that Emacs is an "editor" that does everything (it's not an editor, it is a Lisp interpreter). But I also think that UNIX is a kind of naive formulation of what we now call *"functional programming"* (FP). Lisp is most definitely a proper FP language inspired by the work of mathematician Alonzo Church (the reason why functions are called "lambdas"), Bash is most definitely not. I'll take Lisp function composition over shell pipes any day. I might be wrong, I'll be grateful to accept any criticism of this series of articles here on Reddit.

[deleted]

> 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. Um, yeah, if you define "UNIX Philosophy" in a way that has nothing to do with UNIX as created or used, and then stretch Emacs to fit into the bizarre definition of "functional programming", and wave your hands hard, you can say these things are the same. I like Lisp a lot, but save me from the converts.

> I will take for granted the fact that Lisp is commonly acknowledge to be a FP language, [...] I consider bringing up functional programming in the context of Emacs Lisp to be somewhat of a false argument. All popular general purpose languages are about as functional as the Lisp from back in the day, and idiomatic Emacs Lisp stands out as being very imperative even by Lisp standards. `while`, `dotimes`, dynamic binding, macros, global state for cursor/match data, `progn`, mutable lists, etc. are all non-functional. Once you call Lisp FP, the floodgates have opened for calling any language FP.

>Ok, I admit I didn't read it. As a gray hair, it's been rehashed so many times... I scanned. I think you are substantially correct in your assessment. True enough. I led with the "Emacs is not an editor, it's a Lisp interpreter" argument -- not terribly original. And I did mention Richard P. Gabriel's, "Lisp: Good News, Bad News, How to Win Big" article in the "further reading" section. To my knowledge, the more novel argument that I make is that UNIX is a naive attempt at functional programming (FP), where as Lisp, and thus Emacs, is a proper implementation of FP. >The blog looks nice. If you have time to share how you arrived at that presentation layer I would very much like to know more. Sorry to disappoint, but I coded all the HTML and CSS by hand. I have yet to find a way of generating blog articles from markup in a way I really like. I'll probably get around to rolling my own in Emacs Lisp.

I suppose that is a fair criticism. Sure, most Lisps (especially Emacs Lisp) aren't as functional as a more purely functional language like Haskell. And sure, Lisp is more of a multi-paradigm language with FP being just one of the paradigms. But this series got to be long enough without me trying to go down the rabbit hole of programming language theory, which is why I was so hand-wavy about this part. I guess all I can say is that on a continuum of FP, Emacs Lisp is further toward FP than any of the Bourne-shell family of languages.

>if you define "UNIX Philosophy" in a way that has nothing to do with UNIX as created or used My [stated definition](http://localhost:12222/~ramin_hal9001/articles/emacs-unix-02_what-is-the-unix-philosophy.html#def-minimal) of "The UNIX Philosophy" is basically the Doug McIlroy interpretation that "every program does one thing, and does it well." Do you find this definition controversial? >and then stretch Emacs to fit into the bizarre definition of "functional programming", and wave your hands hard, you can say these things are the same. I am not sure how it is a "stretch" to call Emacs Lisp a functional programming language, or what was bizarre about [my definition of FP](https://tilde.town/~ramin_hal9001/articles/emacs-unix-03_unix-is-lesser-fp.html#a-program-is-a-function ). But I will grant you that there are better FP languages than Lisp nowadays, especially Haskell. If anything is a "stretch" it is my stretching the definition of "The UNIX Philosophy" to the point of it being a naive formulation of FP. I'm saying UNIX is trying to be functional programming with it's shell pipes as function composition, but it falls short. There are also similarities in programming technique with using UNIX CLIs and Lisp REPLs. Ultimately a language where functions are a data type is more useful and functional than a language where the only data structure is a string.

[deleted]

> Not at all. Full disclosure...I have every intention of stealing your CSS. ;-p By all means, I am honored!

You can believe whatever you like, but the creators of pipes AFAIK never related them to FP, FP programs are composed hierarchically with data structures in ways that UNIX pipes and pipelines are not, you somehow dismiss bash which is core to UNIX Philosophy,... the only thing you manage to do is say "unix philosophy which I think is a good thing, is similar to Lispy FP which I like, aren't I super wise in my contrarian take." Whatever. Your take is also not new, other people farted out similar quasi-theology back in the 1990s. (Also, my take is that the UNIX Philosophy never achieved anything more substantial than the AT&T patent drafting system, because undifferentiated streams of 8-bit bytes are not a useful medium for programming, so why bother claiming your favorite things embody it?)

this.

"For people who use Emacs in this way, I would recommend using a lighter-weight text editor like Jed, Jove, MG, Zile, or e3em." This is a bad take.

> the creators of pipes AFAIK never related them to FP, That doesn't support the argument that pipes aren't like FP.

>but the creators of pipes AFAIK never related them to FP You're right about this, I devote all of [part 5](https://tilde.town/~ramin_hal9001/articles/emacs-unix-05_unix-and-lisp-history.html) to discussing exactly that. In short: Kernighan and Ritchie were working on Multics at MIT, but had left by the time John McCarthy set up shop there, UNIX seems to have taken no inspiration from Lisp at all. So the UNIX people stumbled into the idea of expressing function composition in software with their pipes notation. Alfred Aho (the A in AWK) credits the idea of pipes to Doug McIlroy. If only they had known about Lambda Calculus. >you somehow dismiss bash which is core to UNIX Philosophy Not at all. The point I am making is that UNIX pipelines **are** function composition -- output of one functions goes to input of the another. This is core to the UNIX Philosophy. I devote all of [part 3](https://tilde.town/~ramin_hal9001/articles/emacs-unix-03_unix-is-lesser-fp.html) to showing how Bash can kind-of-sort-of do functional programming. I show examples of continuations, anaphoric function calls, and normal and application order evaluation. Eric S. Raymond describes UNIX programs with all of the words simple, small, transparent, robust, modular, readable, flexible, and composable. Does this not sound suspiciously similar to FP principle that functions should be simple, orthogonal, general, composable, easy to reason about? >Whatever. Your take is also not new, other people farted out similar quasi-theology back in the 1990s. I think you have some preconceived notion of what I am writing about here, and you might be surprised to find that I have a different take than what you seem to think it is, if you could kindly spare some of your time to actually read my article. The "*quasi-theology from the 1990s*" you are referring to might be the Richard P. Gabriel essays: "[Lisp: Good News, Bad News, How to Win Big](https://www.dreamsongs.com/WIB.html)." I link to this in my "related reading" section, but my article is making a very different point than this.

Maybe unpopular response: Does it matter?

>Does it matter? Ha ha, not to people like you and me, no. I wrote this mostly for some of my buddies who are fans of Haskell programming as much as I am, but they see Emacs as the antithesis of the UNIX Philosophy simply because it is "an editor that does everything." I find it very strange that people who have a deep understanding of the importance of functional programming would avoid using a Lisp programming language simply because it they believe this particular Lisp is an affront to the UNIX Philosophy, especially since there is some overlap between the UNIX Philosophy and functional programming. If you know anyone like that, maybe you can point them to my article.

[deleted]

> This is a bad take. But if you only use Emacs in the terminal, you never customize your Emacs for anything ever, and you never write any Emacs Lisp, why even use Emacs? If you are only using Emacs because Emacs are the only key bindings you know, why not use a smaller editor with the same key bindings?

Perhaps you'd be interested in seeing how I make use of `org-publish-project-alist` and a pretty small Makefile?

I think the first fallacy in their reasoning is that the Unix philosophy should be as ridged as the notion of "pure functions, always". I feel like it's also misguided to flatten Emacs into "just a text editor that tries to do too much". It is not a text editor. It's a programmable interface. Let's say I wanted to follow the "Unix Philosophy" with Emacs. I would probably avoid using something like Doom Emacs just to get vim bindings, and use Evil or viper mode instead. Also, I regret to inform you that none Lisps are functional programming languages like Haskell is. It has its roots in FP and is well suited for it. However, FP in Lisp requires discipline as the language features do not reinforce "good" behavior. Even common lisp has OOP features.

Yes, please!

[Here you go!](https://github.com/grtcdr/grtcdr.github.io) I hope the README is clear enough about how it all works behind the scenes.

True, Haskell has set a whole new standard by which people judge whether a language is FP. Tail recursion, immutable data structures, and separation of pure and effectful code are all \*expected\* features of a functional language nowadays. But we can always import [Coalton](https://coalton-lang.github.io/20211010-introducing-coalton/), or [Hackett](https://lexi-lambda.github.io/hackett/), or [miniKanren](http://minikanren.org/) into our Lisp program if we need it. As Will Byrd, co-author of MiniKanren once told me, there is no reason you should restrict yourself to the Hindley-Milner type checking algorithm if you know of a better way to ensure the correctness of your program. If people keep introducing OOP programming patterns and globally mutable state into your Lisp program, that is not a problem of the programming language being too permissive, that is a problem of the team leader not explaining to the engineers how to design the system.

Thanks! I'll give it a try sometime soon.

You're very welcome :)

Thanks for those package tips!

>So the UNIX people stumbled into the idea of expressing function composition in software with their pipes notation. Alfred Aho (the A in AWK) credits the idea of pipes to Doug McIlroy. If only they had known about Lambda Calculus. Oh, please, the lambda calculus and functional programming are not occult knowledge that these people were completely ignorant of. Pipes and the shell notation to connect *processes* together were novel operating system features. It's not about functional composition, it's about process I/O channels. >think you have some preconceived notion of what I am writing about here, Whatever, like I said, people discovering Lisp *love* trying to define all sorts of shit to be Lisp in other clothes, what you are talking about is *not* a new thing, it has been said before. Do a Google search for "Emacs UNIX philosophy" and you get links to lots of things [https://news.ycombinator.com/item?id=20374881](https://news.ycombinator.com/item?id=20374881) (from three years ago) >I've been thinking about the whole Unix philosophy vs Emacs and I'm not sure Emacs does not follow it... https://www.reddit.com/r/emacs/comments/7iqebj/does_emacs_violate_the_unix_philosophy_of_doing/ from 2017 https://en.wikibooks.org/wiki/Emacs/Emacs_philosophy which someone started in 2016...I could go on. >The "quasi-theology from the 1990s" you are referring to might be the Richard P. Gabriel essays: No, I'm saying that the "true nature of UNIX" is a theological concept, sort of like people arguing over what the nature of the Trinity is: "Is God separate from Jesus, or are they the same?", and you get disputes and claims of heresy because people disagree. "Does Emacs have UNIX nature?" is a similar religious dispute, getting into what the nature of UNIX is. I'm not calling out to Gabriel (I've read his paper already, you aren't the first person to discover that either), I'm talking about how *you* are spending a bunch of words trying to settle some dispute about whether Emacs is or is not "UNIXy". Who the fuck cares? If Emacs is "UNIXy", it doesn't change a single goddamn thing about what it does or how it is used. Anyhow, Emacs is almost never useful as a component in a UNIX pipeline, for example, as opposed to `sed`. `sed` fits the UNIX philosophy.

> "Emacs is not an editor, it's a Lisp interpreter" argument One other thing: do you realize that Emacs did not start out as a Lisp interpreter? The *original* Emacs was built on the DEC TECO stream editor. RMS and GLS did *not* implement it with Lisp. It was only *later implementations* that used Lisp. Multics Emacs *was* implemented in Lisp (by Bernie Greenberg), as were EINE/ZWEI/ZMACS because those implementations were on Lisp Machines (but you didn't really extend the editor in Lisp, it was just a text editing component, though *everything* on the Lisp machine was defined in Lisp so it isn't a strong distinction). GNU Emacs being based on Elisp didn't happen until RMS decided that GNU needed an Emacs but Common Lisp was "too heavyweight".

There is also that FP programs look nothing like UNIX pipelines.

> GNU Emacs being based on Elisp didn't happen until RMS decided that GNU needed an Emacs but Common Lisp was "too heavyweight". Thanks! I didn't know about this.

Emacs may not be very UNIX, but it's definitely full of the spirit of free software movement. You literally can jump to the sauce code of any commands you are invoking. I doubt there's any day-to-day application that have users reading its source code so much.

Emacs is a Lisp virtual machine, running anything you want (including a text editor) in one process. I guess this the exact opposite of UNIX philosophy, which focus on piping unstructured data between processes.

> Oh, please, the lambda calculus and functional programming are not occult knowledge that these people were completely ignorant of. I can't prove that the UNIX guys never knew about Lambda calculus. All I do know is that in all of the material I read about the development of UNIX, which included some interviews with Kernighan, Pike, Ritchie, Thompson, McIlroy, and Bourne, never once mentioned Lisp or Lambda Calculus. If they did know about Lambda Calculus, either they never talked about it, or I missed the part where they did. > Pipes and the shell notation to connect processes together were novel operating system features. It's not about functional composition, it's about process I/O channels. The fact remains that piping processes links the output of one process to the input of the other, so it is undeniably a form of function composition. > Whatever, like I said, people discovering Lisp love trying to define all sorts of shit to be Lisp in other clothes Mathematics has a tendency to do that: with the right abstraction, concepts that seem to be completely unrelated turn out to be equivalent in some sense. Tea cups are the same as donuts, and so on. Since it is based on Lambda calculus, Lisp tends to make it more obvious when seemingly dissimilar computing concepts are related. > Emacs is almost never useful as a component in a UNIX pipeline True, but if you want to compose Lisp functions with UNIX processes with other Lisp functions, Emacs Lisp can do that by abstracting the UNIX process within a Lisp function. Using Emacs instead of Bash, you have access to a larger pallet of program composition patterns. Eshell is but one example, there are others. > I'm saying that the "true nature of UNIX" is a theological concept, sort of like people arguing over what the nature of the Trinity is Yes, I agree with this. The point of my article is that people should *not* take UNIX as a point of faith, or to take the UNIX Philosophy as a reason to *not* use Emacs or Lisp. I also go into detail about how this is self-contradictory, since UNIX pipes are a form of function composition, and if one loves function composition so much, maybe consider that Lisp does it better. > I'm talking about how you are spending a bunch of words trying to settle some dispute about whether Emacs is or is not "UNIXy". Who the fuck cares? If Emacs is "UNIXy", it doesn't change a single goddamn thing about what it does or how it is used. Don't get me wrong, I am genuinely grateful for you critique of my writing. But I have re-summarized a large portion of my article here in the comments section because you seem to misunderstand my thesis. At this point, a more charitable reading of my article probably could have saved you some time. But if you prefer to learn about other people's opinions in comment format, I am happy to have this conversation with you.

> UNIX philosophy, which focus on piping unstructured data between processes. Yes, but I consider that this is a form of [*function composition*](https://en.wikipedia.org/wiki/Function_composition ) -- the output of one program (function) becomes the input of another. This is an important principle in functional programming (FP). Lisp is the first FP language, and Emacs is a Lisp interpreter. This makes Emacs Lisp a powerful mechanism for composing functions. For example, applications like Eshell can wrap a UNIX process within a Lisp function so that it can be composed with other Lisp functions, and Lisp functions can be composed with UNIX Processes. If the UNIX Philosophy is really about function composition, Emacs is actually very good at this.

My argument is that using UNIX pipes to join processes together is a form of [*function composition*](https://en.wikipedia.org/wiki/Function_composition ) -- the output of one program (function) becomes the input of another. This is an important principle in functional programming (FP). Lisp is the first FP language, and Emacs is a Lisp interpreter. This makes Emacs Lisp a powerful mechanism for composing functions. For example, applications like Eshell can wrap a UNIX process within a Lisp function so that it can be composed with other Lisp functions, and Lisp functions can be composed with UNIX Processes. If the UNIX Philosophy is really about function composition, Emacs is actually very good at this.

I’m not sure UNIX pipes and function composition are analogous like that. Pipes are objects on their own: can be named, redirected, are buffered, etc. Pipes are decoupled from the processes that write or read to it. Piping data from one process to another doesn’t give you a new process. OTH, function composition is not an object of its own, it’s abstract. Composing two functions gives you a new function. Function composition does not implicate on buffering or blocking. UNIX with its processes and pipes is actually a lot more like the architecture of OO with actors and message passing like Smalltalk, or CSP with threads and channels like Go, than just function composition of functional programming.

Emacs is like the X server, or the Unix kernel itself: it does not follow the Unix philosophy in its own right, but it provides services for programs that do, strengthening them and allowing for better integration between them. I've found that using Emacs as a "super-shell", scriptable in Lisp, to tie Unix programs together and provide an interactive interface to control them, is like a jet booster for my productivity. And it usually takes a page or less of Emacs Lisp to add at-your-fingertips functionality this way.

Frankly my dear... While you and others spend hours to discuss whether emacs does fulfil this or that philosophy. I'll start doing whatever it is that I have to do and be done with it before the discussion is still going on. In the end it does not matter. It's a tool, use it as such. If a better tool comes along switch to that.

> Pipes are objects on their own: can be named, redirected, are buffered, etc. > > .... > > Composing two functions gives you a new function. Function composition does not implicate on buffering or blocking. These are implementation details. The UNIX Philosophy is not so much about implementation as it is about how to design programs so that they can be composed (like functions) in a process pipeline. This higher-level concept is function composition in the sense that an input of one function goes to the output of another. But it is true that the POSIX implementation of process pipelines is not as clean as Lisp function composition, which is one way in which the UNIX programming environment falls short of actual functional programming. > UNIX with its processes and pipes is actually a lot more like the architecture of OO with actors and message passing like Smalltalk, or CSP with threads and channels like Go Well, I don't think so. A Smalltalk method can send messages to lots of different other objects, it is not so easy to do this in UNIX without some hack to creates lots of temporary FIFOs. Bourne shell languages can do this, but it isn't really built-in to the language. Haskell also provides mutexes, channels, and green threads, so it can model Smalltalk message passing, Go-routines, and UNIX process pipelines with some combination of these primitives and Monads. This demonstrates how Lambda Calculus is a much more powerful abstraction than UNIX shell programming, and why I encourage functional programming (e.g. with Emacs Lisp) over UNIX shell programming.

> it does not follow the Unix philosophy in its own right, but it provides services for programs that do, strengthening them and allowing for better integration between them. I've found that using Emacs as a "super-shell", scriptable in Lisp, to tie Unix programs together and provide an interactive interface to control them Yes, this is a very good way of putting it! Although if you consider Emacs as a programming language, it does follow the UNIX philosophy in that "it does one thing and does it well" (it interprets Lisp code). But the bigger point I am trying to make isn't really that it is a good thing that Emacs follows the UNIX philosophy. What I am saying is that the UNIX philosophy should not be taken as a point of faith, and that functional programming is a better set of principles to follow. And like you say, Emacs is like a super-shell that lets you do this.

> spend hours to discuss whether Emacs does fulfil this or that philosophy Believe it or not, a lot of people use the UNIX Philosophy as a reason for why they should *not* use Emacs. My article is really to try to convince these people that it is nonsense to complain about Emacs not following the UNIX philosophy. I give two main reasons. Firstly that Emacs is not an editor but a Lisp interpreter, so all the "cruft" that comes with it are actually "apps" or "libraries," not cruft. Secondly, and more importantly, the UNIX Philosophy seems to be a naive formulation of functional programming (shell pipelines are a kind of function composition), and so if you agree that functional programming is a good set of principles to follow, this is even more reason to use Emacs, which is an interactive Lisp programming environment, and Lisp is a functional programming language.

What are they "Lisp standards"? Because Common Lisp (the actual, you know, Lisp standard) has the loop construct…

Emacs is Lisp machine without the dedicated hardware…

My use of the word *standards* was to mean the norm, not an explicit standardization. The point is that while there are Lisp dialects that are more declarative in nature, if you look at Emacs Lisp code in the wild, most forms are there entirely for their side-effects, in a very imperative fashion. The CL loop macro (which also exists in Emacs Lisp...) is a good example, where, in my honest opinion, it is too inflexibile to the point where you often have to fall back to mutable state in order to express things that are easily done with - I guess - more modern map/fold/filter/scan iterator chains in other languages. I.e. I think that Rust's `Iterator`, JavaScript's `Array`, Java's `Stream`, (Haskell's `List`,) do a much better better job at expressing what I want declaratively than Lisp, but still it is Lisp that is touted as somehow being *functional*.

Of course it does. Emacs is a programming environment, not just a program. Saying "Emacs does too much" is like saying "the shell does too much". Not going to join the debate over FP and UNIX philosophy, but just to suffice to say that the UNIX philosophy was not something contrived after creating UNIX, but the opposite. Both UNIX and the Lisp Machines at MIT were suppose to be an implementation of these "best practices". From Eric Raymond's "The Art of UNIX Programming" [http://www.catb.org/\~esr/writings/taoup/html/ch01s06.html](http://www.catb.org/~esr/writings/taoup/html/ch01s06.html) Eric also points out in this book that both UNIX and Lisp traditions eventually converged with the rise of the open source movement. Emacs is the brainchild from the Lisp tradition.

Thank you for that in-depth dive. It clears up a lot of confusion people are throwing around about CS "philosophies" without actually looking at their stuff, like you did. Congrats!

Yes, I paraphrased much of Eric S. Raymond's 17 rules from the *Art of Unix Programming* in [part 2](https://tilde.town/~ramin_hal9001/articles/emacs-unix-02_what-is-the-unix-philosophy.html) of this series, but I did so in order to draw attention to the fact that these 17 "rules" (modularity, clarity, composition, separation, simplicity, etc.) are suspiciously similar to the principles of writing functions in an FP language (simple, orthogonal, general, composable, etc.) FP and Lambda Calculus are not "folk traditions," and I see this as a better, more clear way of thinking of problem solving. Raymond seems to think of the lack of precision as a strength of the UNIX Philosophy: >*"The Unix philosophy (like successful folk traditions in other engineering disciplines) is bottom-up, not top-down. It is pragmatic and grounded in experience. It is not to be found in official methods and standards, but rather in the implicit half-reflexive knowledge, the expertise that the Unix culture transmits. It encourages a sense of proportion and skepticism — and shows both by having a sense of (often subversive) humor."* The problem is that people mistakenly view this philosophy as dogma. This series of articles I wrote is a warning against this dogmatic view, especially for people who are using the UNIX Philosophy as an excuse to dismiss Emacs as some "bloated editor." FP is not "folk tradition," so it is harder to misunderstand as dogma. A function is either pure or it has side effects, there is no philosophical debate about it. A data structure is immutable or mutable, again no need for debate. A higher-order function is useful for you or it isn't.

> but they see Emacs as the antithesis of the UNIX Philosophy simply because it is "an editor that does everything. `bash` is an antithesis, so `find` and `grep` are, but I suppose they still use it on daily basis.

I didn't read the article so take this with a grain of salt, but it seems to me that the "clash" between emacs and the unix philosophy is (or should be) that the monolithic **program** or OS or whatever you want to call it emacs does not fit within the unix philosophy of >Make each **program** do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". As mentioned it is rarely useful in a UNIX environment compared to other, in my opinion more UNIXy software (grep, sed, awk, cat, less etc). I'm aware you can accomplish the same thing from within Emacs but thats kinda besides the point. And yes it is a philosophy that can and should be applied in more fine grained aspects of software development, and I'm sure lisp/elisp is great for that purpose but to me at least it is a philosophy on a level above your chosen tool of implementation. I don't know, I feel like if you are saying that Emacs abides to the UNIX philosophy because FP programming principles do, it's kind of the same as saying "since I can write orthogonal, maintainable and reusable functions and modules in C++, Adobe Photoshop abides...".

I prefer to spend hours configuring Emacs myself. Emacs is after all by far the superior Emacs configuration tool.

(while (re-search-forward (rx "This is a bad take.") nil t) (replace-match "I disagree, because "))

IMO the controversy comes from trying to fit a square box into a round box, i.e. trying to confine Emacs to the expectations of a Unix process or program. Instead, one should open his mind to the idea that Emacs is an environment, like Unix is; that it happens to live within the Unix environment (or Windows, or DOS, or any OS) is an implementation detail. Imagine a world without false dichotomies...

Friendly, if unsolicited, advice: There are those who "get it," those who don't, and those who won't. Limit the amount of time you spend trying to convince those who won't; it could be better spent. ;)

In the bigger picture, the problem is that of labels: the mental boxes we put things in, and our biases toward and against them. It's one of the weaknesses of human nature--yet to some degree necessary, for without categories by which to understand things, we couldn't function. As DrPiwi pointed out, who cares? Emacs, Unix--they're all useful tools in their own paradigms. If some want to religiously adhere to one and abstain from the other, that's their prerogative, but we need not so limit ourselves.

You are a generous fellow. Of course, imitation is the greatest form of flattery. :)

This comment of yours--this one is good. ;)

Do you define a *functional language* as *one in which only functional paradigms may be used*, or *one in which functional paradigms may be used*?

Thanks, I look forward to reading some of this as I have time. I'll first offer a small quibble: while I agree that Emacs is a platform, I don't agree with your statement that "Emacs does not have extensions, it has apps." While applications are certainly written for the Emacs platform, any such application is necessarily an extension of it, because they are loaded into a Lisp image, in which there are no boundaries (unlike an OS/process model). Of course, Emacs jargon doesn't refer to them as *extensions*, but neither does it refer to them as *applications*--nevertheless, they are both.

>The fact remains that piping processes links the output of one process to the input of the other, so it is undeniably a form of function composition. You keep saying "pipes are like function composition", and, frankly, I think that is a useless analogy. Mathematical functions have a domain and a range. A pure function maps values from the domain into values in the range. What are pipes doing here? A unix executable is an impure function, mapping "whatever appears on stdin" to "whatever I spew on stdout" with additional dependencies on the entire computing environment: file system, command-line flags, environment variables, external events and signals....and unbounded side-effects like writing files anywhere or making I/O happen or sending e-mails or whatever. Pretending this arbitrary dynamic and impure computation resembles some pure function is just stupid. Like, really, what FP programming looks like this? I think the brokenness of this analogy is what makes me reject your thesis. There are plenty of other issues, for instance, the people who had the UNIX philosophy carried it on into Plan 9: here's what Plan 9 has to say about Emacs [http://man.cat-v.org/plan\_9/1/emacs](http://man.cat-v.org/plan_9/1/emacs) They have their own thing, they call sam. [http://man.cat-v.org/plan\_9/1/sam](http://man.cat-v.org/plan_9/1/sam) or Acme http://acme.cat-v.org Another issue: you appear to take ESR seriously as an authority.

> any such application is necessarily an extension of it, because they are loaded into a Lisp image, in which there are no boundaries (unlike an OS/process model) Thanks for your feedback! So far, you have provided the most constructive criticism. You make a good point that "application" may not be the best term for it. I still find the term "app" (which is more of a marketing term nowadays) to be instructive way to describe Emacs Lisp packages for people who are trying to learn more about Emacs. But I'll keep what you said here in mind.

> You keep saying "pipes are like function composition", and, frankly, I think that is a useless analogy. > > Mathematical functions have a domain and a range. A pure function maps values from the domain into values in the range. > > What are pipes doing here? A unix executable is an impure function, mapping "whatever appears on stdin" to "whatever I spew on stdout" with additional dependencies on the entire computing environment > > I think the brokenness of this analogy is what makes me reject your thesis. It is very true what you say, that UNIX executables are **impure** functions, but impure functions are still functions. Though there may be a distinction between pure functions and impure functions, they both have the property of being composable. Maybe it is just that I am from the Haskell school of thought, but I see no need to restrict your definition of function to that of a "pure function with a domain and range," at least, not when it comes to modeling computer processes as functions. In Haskell we just give impure functions a different type with a different composition operator: `.` for pure functions, `<=<` for impure functions. The different types lets the type checker ensure that you combine pure and impure functions in a rigorous way, for example using the Applicative type class for applicative order evaluation of pure functions. > the people who had the UNIX philosophy carried it on into Plan 9: here's what Plan 9 has to say about Emacs http://man.cat-v.org/plan_9/1/emacs > > They have their own thing, they call sam. http://man.cat-v.org/plan_9/1/sam or Acme http://acme.cat-v.org I didn't know about this either, thanks! > Another issue: you appear to take ESR seriously as an authority. OK, this does hurt my feelings a little. I do not take Raymond's political opinions seriously at all, I genuinely do not like the guy. But he did write a popular book on the UNIX philosophy which many people still seem to take seriously, so in that sense he is an "authority." I figured if I am going to argue against the UNIX philosophy, I should at least address what he said about it.

[removed]

>But he did write a popular book on the UNIX philosophy which many people still seem to take seriously, so in that sense he is an "authority." Bashing ESR is one of my favorite activities, [https://www.reddit.com/r/lisp/comments/1b1wbl/comment/c93j0sw](https://www.reddit.com/r/lisp/comments/1b1wbl/comment/c93j0sw) [https://www.reddit.com/r/programming/comments/j2k9ph/comment/g75yfrq](https://www.reddit.com/r/programming/comments/j2k9ph/comment/g75yfrq) so I'm possibly a little biased, but, seriously, ESR claiming to describe the "UNIX philosophy" and to declare "Open Source" as subsuming both is just part of his pattern of self-aggrandizement and self-promotion. Yeah, he wrote a book. The UNIX people actually wrote an entire follow-on operating system, Plan 9, which I take to be a much more reliable source on what they were trying to accomplish. It really does not make sense to try to build grand philosophy on the basis of one dude whose main technical contributions are things like adding blindfolds to nethack. [https://www.reddit.com/r/programming/comments/j2k9ph/comment/g7618ul/?utm\_source=share&utm\_medium=web2x&context=3](https://www.reddit.com/r/programming/comments/j2k9ph/comment/g7618ul/?utm_source=share&utm_medium=web2x&context=3)

>No, I'm saying that the "true nature of UNIX" is a theological concept, Oh, please! The true nature of UNIX is that it is a software tool. It may have some kind of system of working behind it, some general thought of how to organize tools and such, but the main Idea was to get thing working as simple as possible using the least amount of resources. And since it was written by programmers for programmers it got the style of no output when noting is wrong and the concept of every thing is a file as these were the simplest and most general abstractions that could be made. Theological concepts only matter to someone if they are religious, and most people are not religious about computers. And a lot of people are atheists and get really annoyed when some zealot tries to turn everything in to religion. Being an atheist does not mean being an anti-christ or religion hater, just that one does not believe there is a god or that . religion is necessary. So to get back on track, UNIX and Linux are tools nothing more, nothing less.

The theology comes about when people like OP elevate their tools into objects of worship. I don't think it is problematic for users of tools to try to think about how their tools can be made to work more effectively for their purpose. The extreme flexibility of software also leads us to think very abstractly about the nature of the tools. The people developing UNIX, as you seem to acknowledge, thought purposefully about how they worked and could work better. I think it might have been Thompson who thought it important and novel that files were untyped, so that a program could take the output of the compiler as an input without special effort. Or that the command shell was an ordinary user process. I am not particularly convinced that all of these are advances, but the people developing UNIX did. They also felt pipes and exposing devices as file paths and so on were all important contributions. Once you have enough of these ideas, there has to be some principles developed so that the expression of the ideas is carried through. All this is fine. Where people start elevating principles too far, and claiming them as good beyond their original scope, it gets too religious. I don't think it is useful to search for UNIX nature in things like Emacs.