@Zach  🇮🇱 🇺🇸

I think you're basically correct to point out that Emacs does not adhere to the unix philosophy as it is classically understood.

The locus classicus is presumably the widely quoted McIlroy et. al. in the 'Unix Time-Sharing System" where Emacs clearly violates the first maxim:

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features."

Or to take a later articulation, Gancarz in Linux and the Unix Philosophy's first two tenets: 'Small is Beautiful', 'Each Program Does One Thing Well'  — again Emacs is the opposite of this.

(This kind of thing comes up constantly in every mention of the Unix philosophy that I've ever seen until this conversation and is easily verified by simply searching.  It's strange to see people insisting that there is simply no emphasis on small, special purpose programs. Of course one can decide that principle isn't important, but let's not ignore that it was (and I believe usually still is) considered to be so)

We can also note that in the original incarnation of Unix ('Research Unix') there was nothing remotely like emacs and there was, as far as I know, very little scriptability.  The Thompson shell allowed for piping but not scripting.  OG unix is everything is written in C, with a simple interactive shell and if you want anything else it's back to C programming.

Whereas Emacs does (as you say) have more in common with the Lisp ethos, where there aren't separate programs per se and everything is a function in one giant Lisp environment (same is true of Smalltalk) — although there are differences there, too which I might get on to later.

I think it pays to note that these views are informed by very different language traditions.  C is a static language with an explicit and slow compilation step.  Lisp on the other hand has always been a dynamic language where you can just throw a new function into your environment pretty much immediately, usually without having to (explicitly) compile or restart anything.

If you think about it a bit you might start to see that if all you've got is C, small programs that don't keep their own state but write to text files may be the simplest option for getting any composibility, particularly on limited machines.

However, I think we can fairly say that Unix found that only having a statically compiled language available was far too limiting and early on started haltingly down a path to acquiring dynamic programming abilities, starting with scriptable shells, and later larger programs with their own scripting languages.

People often cite the Unix philosophy as though it's obviously the right way to program.  Modularity, clear interfaces, and composibilty we all think are good things, of course.  But why is 'one program does one thing' better - or even equal to - 'one function does one thing'?

#emacs #lisp #unix

@Zach  🇮🇱 🇺🇸

To continue from where I left off, the pure Unix conception didn't envisage dynamic languages and scriptability and explicitly eshewed large programs.  The utility of (some) dynamism was realised early, but corrected in hamstrung sort of ways — especially from a Lisp perspective,  but anyone can see the limitations of shell scripting languages.

And the 'small programs' in practice has not played out either.  X isn't small, vim isn't small (not by trad Unix standards - it's similar order of magnitude to emacs in fact), webbrowser aren't small...  

The other side of the equation is that the Lisp (esp. in the form of Lisp Machines)/Smalltalk world supposed that you would live entirely within the environment and everything would be written in the one language.  The notion of interoperating with anything outside this was alien and resisted.  It was some years, I believe, before a C compiler became available for Lisp Machines.

Emacs transcends all of this.  It participates in the Unix world just fine.  If you want to load, edit something, and exit, you can do that (if it's running in the background as a server, this is plenty fast, too, as you're just executing emacsclient).  If you want to use it as a filter on the command line, it can do that too, as has been demonstrated.

And the unix world is also available from within emacs.  You can filter or send any block of text through external commands, it has wrappers for classic unix tools like grep, also modes for interacting with shells, terminal emulators, and its own shell from which you can run both elisp functions and unix commands together.

(And, of course, it's great at handling Unix's common data format: text.)

Moreover, org-mode has a great multilingual environment where you run source code in numerous languages and even pass data between them with ease.  


This is all completely the opposite of the Lisp Machine/Smalltalk notion of an isolated world.  It's more in line with the Unix shell, which doesn't care what your programs are written, except better.

So I think we can say it transcends the two purisms.  It does this by rejecting the 'small specialized program' dictum (which I don't think is important and I'd argue has been effectively rejected by all but the most purist Unix-heads), and centering itself in place of a unix shell (without demanding this) but keeping to the spirit of all the other ideas.   And on the other hand, also rejecting Lisp Machine solipsism.

(I haven't really thought of this in quite this way before so thanks for the discussion, in particular @Zenie who pushed the idea that emacs is actually better at what's important about unix than unix is, and @restorante and @eruwero's demonstration of emacs as a unix command line tool)

#emacs #lisp #unix

@Zenie

I've been meaning to ask you:  why do you consider vim to be a poor vi?  And why is Evil (if I've remembered the right mode) better?

(I don't have any opinions about this; I'm just interested)

#vi