Very good question. A lot of the time "Write programs that do one thing and do it well" really means "I don't understand the difference between a procedure and a program." It is much easier to write procedures than it is to write programs, and it is often easier to turn a procedure into a program than vice-versa (emacsclient does the former especially well). Emacs is much better at "Writ[ing] programs to work together" - Emacs extensions usually work with each other without any extra effort, and deep integration is easy to achieve. "Write programs to handle text streams, because that is a universal interface" is the reason why Unix utilities do not integrate well.

To provide an example, I use mu4e[1] as an email client and reader, which uses a separate process running mu to operate on a Maildir. The Maildir is synchronized to multiple MDAs by OfflineIMAP, a command line program, which I set up to retrieve the IMAP passwords from an encrypted file using auth-source.el by execing emacsclient. With auth-source, all the credentials I need to access remote machines are in one GPG encrypted file, and Emacs takes care of handling communications with GPG, gpg-agent, and pinentry.

So Emacs provides both a better way to work with other standalone programs, and, via the emacsclient/server model, a better way for standalone programs to work with Elisp code.

[1] http://www.djcbsoftware.nl/code/mu/ [2] http://www.offlineimap.org/

It doesn't, because "the Unix philosophy", in the meaning implied by your question, is oversimplified nonsense. There is both utility and architectural value to be found in integrated user experiences. To throw out just a few small examples, such experiences done well may reduce context switching and/or build on the user's deep skills in the integrated environment (esp. w/ Emacs' and vim's text manipulation support). Likewise, there is immense utility in a scriptable, user-programmable working environment, especially for developer's tools.

Also note that Emacs and vim often comply with the oft-cited first bullet point (there's more than one!) of "the Unix philosophy" by reusing powerful yet single-purpose external tools under the hood. Case in point: git(this thread!), ag/ack, and so forth.

So please forget the idea that bullet-point-one of the Unix philosophy is a sacred tablet from some ridiculous Unixy religion. It's just an old, occasionally useful, architectural rule of thumb that applies in relatively narrow circumstances relative to the breadth of modern computing experiences and implementations.

It does and it doesn't.

Emacs is a Lisp environment / runtime and is composed of many small functions. So in a way it is similar to the Unix philosphy, except it runs on Lisp.

It's like saying a shell doesn't follow the Unix philosophy because it runs other programs.

Each package does one thing, presumably well, is interchangable, customizable, and interops with everything else.

Don't remember where I read this quote, but it sums up the situation pretty perfectly:

> Emacs is a Lisp refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Lisp philosophy. But it integrates...

Emacs (~1976/1978) roughy predates Unix and came from a very different tradition (and FWIW wasn't originally written in Lisp either)