Hacker News Reader

Comment by sn41 | Hacker News Reader

The principle of writing a fast core in C, and choosing a Turing-complete language as the language to build the tool, and further giving the user an interpreter so that (s)he can extend it, is a brilliant design. Whether or not you are a Lisp fan or an Emacs user, this is a great way to build a sophisticated tool.

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.

View on HN

I've been thinking about the whole Unix philosophy vs Emacs and I'm not sure Emacs does not follow it: according to Wikipedia: 'GNU Emacs, describes it as "the extensible, customizable, self-documenting, real-time display editor"'.

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.

I'm waiting for the day when somebody writes a Neovim frontend in Emacs, so I can literally use Vim from inside Emacs.

In the days when I used an embedded terminal in emacs (adcii term or something, I can't quite recall), I at one point used vim to open a filw in that terminal, and lo and behold, it actually functioned pretty well. So I finished editing the file and then realized what I'd just done and spent the rest of the day laughing! (:

You can already almost use Vim from inside Emacs via Evil mode.

What of vim are you missing from Emacs' Evil mode?

Yeah, Emacs follows UNIX philosophy only in the edge case of "doing one thing" being doing everything that's even tangentially related to or representable as text. It technically conforms, but kind of goes against the spirit :).

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.

Agreed. One of the pillars of Unix philosophy is stdin/out and pipes. Emacs balatantly ignores them.

If it didn't ignore them, how would it use them and what would it be able to do better? Genuine question.

>Yeah, Emacs follows UNIX philosophy only in the edge case of "doing one thing" being doing everything that's even tangentially related to or representable as tex.

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.

On the other hand, don't look at emacs as a tool on Unix, look at it as a tool like Unix... it has a few simple abstractions (text, buffers, windows) and presents to the User a programmable shell to act on those abstractions.

In short: Emacs runs elisp and does it well.

Does any GUI application follow the Unix philosophy very well? Because the other side of "do one thing and do it well" is that arbitrary tools can be combined, and that tends to break down once you leave the command line.

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".

> Does any GUI application follow the Unix philosophy very well? Because the other side of "do one thing and do it well" is that arbitrary tools can be combined, and that tends to break down once you leave the command line.

Building scriptable applications works relatively well: see OSA on macOS.

It's funny that you should call magit "clumsy", implicitly opposing it to Git's CLI.

> by wrapping existing tools

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.

That's basically the approach used by web browsers, too. (JavaScript even has a Symbol type now!) This architecture has long been an under-appreciated aspect of the Lisp way.

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.

Emacs does one thing and does it well. That thing is being an editor construction kit (or maybe an operating system, depending on your point of view).

Reply on news.ycombinator.com