While the unix tool philosophy is to do one thing and do it well, Emacs shows that it is possible to build software which lasts 50 years by going the other way as well, as long as there is a philosophy of empowering the user.
And it does it very well! It just turns out that "extensible, customizable, self-documenting, real-time display editor" is really powerful. Wanna display text in a way that makes it easier to edit code? Evil. Wanna display text so its easy to interact with Git? Magit. Wanna display text so that its easy to navigate your file system? Dired. And so on.
Emacs "just" lets you display and interact with text on your screen, and it does it very well. I didn't think much of text UIs until I used Magit.
Emacs is really best seen as a platform for running Emacs Lisp software. An OS within an OS. It just happens it's optimized for text editing, and it ships by default with a text editor.
I think that is the right idea, but it can be reworded to:
>Yeah, Emacs follows UNIX philosophy only in the case of "doing one thing" by being an interactive, turing complete, generic text processor.
Emacs tries to work with the command line; it can run a terminal inside it, or run commands on a buffer with M-|. And emacsclient --eval can run a Elisp from the terminal. But...
> Wanna display text so its easy to interact with Git? Magit. Wanna display text so that its easy to navigate your file system? Dired.
That nicely highlights the way Emacs usually interacts: by wrapping existing tools rather clumsily with a lot of Elisp.
And it's forced to do this because the other Unix philosophy of "everything is a file" has made it very difficult to evolve beyond the command line.
Which is not to say Unix was wrong: the command line is very good at what it does and lots of other schemes following it have crashed and burned because "do one thing and do it well" often conflicts with their more complex notion of "everything is an X".
So you propose emacs should write it's own version of everything, instead of using existing functionality?
> rather clumsily
That's a highly subjective view, if not weasel words.
> with a lot of Elisp.
How does the amount of lisp even matter so long as it gets the job done well?
Anyway, dired's great (in your view where does it fall short - honest question) and while I've never used magit I've heard not a single bad word against it.
Building scriptable applications works relatively well: see OSA on macOS.
On the internet, I often hear programmers talk about how great the Unix philosophy is, but hardly anybody follows it any more. They may not be using s-exps but everybody is building their programs around the Lisp philosophy.
Pulling open a live inspector, digging into rich data structures, and running interpreted ad-hoc code? That's not exactly Unix you're practicing.
This seems important.
The internal struggle in the MIT AT Lab due to Lisp and Symbolics seems more interesting than I thought. I read Wikipedia, and it says "there were two AI Lab people who choose not to be employed by either: Richard Stallman and Marvin Minsky". Wow, I never expected to see these two names in the same line.
Are there any good book that covers this part of the history and its connection to the later development of free software movement?
It should be too surprising as it took place at the MIT, but many of the founders of Lisp were present. Dan, Guy Steele, Richard Gabriel, JonL White, and so many more. It was really inspiring.
Interestingly, though the ILC is a conference about all flavous of Lisp and its applications, RMS wasn't attending the conference.
Perhaps it wasn't apparent widely, but it was certainly clear to MSFT and IBM. IBM lawyers at the time refused to allow RMS to come speak at the Watson lab where I worked, because of his ideas about free software.
 is also going nowhere since again no Emacs core developer is interested in it and to top it off, they’re well on the path to creating something even more complicated and harder to understand than Emacs’s C core.
These are _good_ developments since GNU Emacs is progressing rapidly on its own merits.
Making a portable OS kernel is a much larger project than making a non-portable kernel, and the focus on 386 based PCs allowed for getting something useful up and running quickly.
The 386 was a runaway winner, and it was pretty clear from the day Compaq released the first 386 powered PC that 386 was the future. It allowed virtualization of 8086 apps (so you could multitask with existing software, which was a huge selling point at the time). It had virtual memory, a critical feature when lots of RAM was 4MB. It also had preemptive multitasking and allowed you to have a flat memory model (even though the 386 memory model was segmented). All the things you need to make a really nice Unix like OS.
Other options were either an order of magnitude less popular (i.e. use Motorola 68030 based computer) or technically limiting (use a 286 based PC which had some brutal limitations with memory access).
IIRC Linus specified the features of the 386 that you mention as being a reason for not just porting Minix; Minix wanted to be system agnostic so would not easily be made to be performant on the i386.
IMO, focusing on a single system allowed for rapid development of features, and as you say the 386 was not an obvious choice for "workstations" which is probably where RMS was thinking.