4 ms·

Completely agree with this. Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Vis

by gw98 4y ago

Completely agree with this. Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio. Honestly in the 30 years I've been using Unixes I have never needed anything but vi/vim with a few lines of configuration, mostly to satisfy some of the newer fussier language indent requirements (yaml, python). Most of the non trivial data processing is done with external tools (sed, grep, awk etc) where the knowledge and power is reusable for other tasks external to editing things! Only on Windows have I had to leverage anything more complicated.

agumonkey 4y ago
I think there's strange rotation. Emacs being based on lisp is all about composing lots of individual bits. Unix too.
- gw98 4y ago
  Indeed. But it's a nested abstraction.
ParetoOptimal 4y ago
> Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio. Only if you consider emacs as a tool rather than a tool-maker.
- pjmlp 4y ago
  Emacs is a Lisp machine with a text editor as sample application.
__d 4y ago
I think it's a common misconception that Emacs is not a collection of simple tools. There are two major differences: Emacs' "shell" is the ELisp interpreter, not (eg) bash; and, Unix uses the whitespace-separated text stream as its common language, and Emacs uses the text buffer. There are analogous tools in both environments, although in Emacs, most of the "little language"-driven tools use ELisp instead, giving simpler cooperation. There's a lot of truth in the "Unix is just a device driver collection for Emacs" model though: there's little need for most of the Unix toolset if you're adept at Emacs. I think there's a much more interesting discussion to be had in comparing the relative merits of text streams (Unix) vs text buffers (Emacs) as a unifying abstraction for a suite of programmer's tools.
- gw98 4y ago
  I'm well aware of how Emacs works. mg probaly fits better. It's just an editor. One small component.
MichaelCollins 4y ago
> Unix is centred around composing lots of individual tools that do one job well. By this standard, the Unix philosophy has never been realized. Even when the tools work as advertised, they're hardly doing it well. How do you delete a file called -foo? `rm -- -foo`. Do you know what -- is? It's kludge! It's kludge that needs to exist because Unix's entire paradigm of argument passing is legacy crap. And historically, the tools didn't even work as advertised. Before GNU came along, there used to be all kinds of hidden landmines in common Unix utilities, like tools which silently truncated long output lines because they were using static buffers instead of dynamic memory allocation. GNU's style guide specifically warns against doing this, because it used to be the Unix status quo. Things like this get left out of the romantic tales of Unix's history, leading newbies to view Unix with rose tinted glasses. As for "doing one thing", nobody even knows what that means. What is the difference between one thing and two things? Should rm not be able to remove directories because rmdir exists? That's subjective, what qualifies as "one thing" is inherently subjective.
- legends2k 4y ago
  Thanks for your answer. Never realised the overlap between rm and rmdir. Actually the philosophy is a nice guideline but blindly holding on to it for the heck of it is childish. Your comment made me realise that.
- gw98 4y ago
  Oh completely agree. But the philosophy is spot on. I've applied it to many problems over the years successfully outside the domain of Unix. The reality is however less than ideal.
- b112 4y ago
  Agree, but don't like your rm example. rm -- just means end of args, and it can conveniently be left off. That's not a kludge, it's a feature. A feature that many command line utils (GNU grep) support.
  - legends2k 4y ago
    It's kludge since you are special casing for some files and not for others e.g. rm abc vs rm -- -xyz. If Unix utilities had a different form of specifying args which didn't meddle/overlap with file names this kludge wouldn't have to exist.

by gw98 4y ago

agumonkey 4y ago

I think there's strange rotation. Emacs being based on lisp is all about composing lots of individual bits. Unix too.

gw98 4y ago
Indeed. But it's a nested abstraction.

ParetoOptimal 4y ago

> Unix is centred around composing lots of individual tools that do one job well. Emacs is the antithesis of this. It's closer to Visual Studio. Only if you consider emacs as a tool rather than a tool-maker.

pjmlp 4y ago
Emacs is a Lisp machine with a text editor as sample application.

__d 4y ago

I think it's a common misconception that Emacs is not a collection of simple tools. There are two major differences: Emacs' "shell" is the ELisp interpreter, not (eg) bash; and, Unix uses the whitespace-separated text stream as its common language, and Emacs uses the text buffer. There are analogous tools in both environments, although in Emacs, most of the "little language"-driven tools use ELisp instead, giving simpler cooperation. There's a lot of truth in the "Unix is just a device driver collection for Emacs" model though: there's little need for most of the Unix toolset if you're adept at Emacs. I think there's a much more interesting discussion to be had in comparing the relative merits of text streams (Unix) vs text buffers (Emacs) as a unifying abstraction for a suite of programmer's tools.

gw98 4y ago
I'm well aware of how Emacs works. mg probaly fits better. It's just an editor. One small component.

MichaelCollins 4y ago

> Unix is centred around composing lots of individual tools that do one job well. By this standard, the Unix philosophy has never been realized. Even when the tools work as advertised, they're hardly doing it well. How do you delete a file called -foo? `rm -- -foo`. Do you know what -- is? It's kludge! It's kludge that needs to exist because Unix's entire paradigm of argument passing is legacy crap. And historically, the tools didn't even work as advertised. Before GNU came along, there used to be all kinds of hidden landmines in common Unix utilities, like tools which silently truncated long output lines because they were using static buffers instead of dynamic memory allocation. GNU's style guide specifically warns against doing this, because it used to be the Unix status quo. Things like this get left out of the romantic tales of Unix's history, leading newbies to view Unix with rose tinted glasses. As for "doing one thing", nobody even knows what that means. What is the difference between one thing and two things? Should rm not be able to remove directories because rmdir exists? That's subjective, what qualifies as "one thing" is inherently subjective.

legends2k 4y ago
Thanks for your answer. Never realised the overlap between rm and rmdir. Actually the philosophy is a nice guideline but blindly holding on to it for the heck of it is childish. Your comment made me realise that.
gw98 4y ago
Oh completely agree. But the philosophy is spot on. I've applied it to many problems over the years successfully outside the domain of Unix. The reality is however less than ideal.
b112 4y ago
Agree, but don't like your rm example. rm -- just means end of args, and it can conveniently be left off. That's not a kludge, it's a feature. A feature that many command line utils (GNU grep) support.
- legends2k 4y ago
  It's kludge since you are special casing for some files and not for others e.g. rm abc vs rm -- -xyz. If Unix utilities had a different form of specifying args which didn't meddle/overlap with file names this kludge wouldn't have to exist.