3 ms·

> One of my favourite features of Dired is the ability to mark or unmark multiple files in a variety of ways: manually, using repetition counts, or with regular

> One of my favourite features of Dired is the ability to mark or unmark multiple files in a variety of ways: manually, using repetition counts, or with regular expressions. This can be done fluidly and spontaneously as we browse and inspect files. Once we're satisfied with our selection, we can perform bulk operations on them such as copying, moving, deleting, changing permission bits, compressing the marked files, etc. That does sound cool. Emacs sounds like the type of app I would have loved back when DOS was still a thing, but now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time.

chungy 1y ago
Emacs, and GNU at large, never cared for Eric Raymond's idea of "do one thing and one thing only" being the Unix way. They freely make large do-everything programs.
- JCattheATM 1y ago
  What are some other examples of them doing so aside from Emacs?
bradain 1y ago
Emacs isn't really a follower of the unix philosophy since it's more a hold-over from the world of lisp machines. Emacs also eschews the "everything is a file" philosophy of unix (programs in emacs are just lisp functions) and the idea of storing / transmitting data as plain text, instead using lisp data structures to do that. Lisp itself is kind of antithetical to the unix philosophy too when compared with C. Lisp is presents an extremely simple, totally consistent core that is extremely difficult to implement efficient compilers for. C on the other hand was designed from the outset with the goal of being easy to write compilers for. Requirements for having function prototypes ahead of uses, having all variables declared at the top of a function, etc were done to make it easier to implement. Almost a perfect example of worse is better, really. Check out the unix hater's handbook if you haven't, that sums up pretty nicely the world that emacs hails from.
- anthk 1y ago
  Did you check SBCL? It's pretty fast. On easy compiler, GCC and Clang are nightmare. Maybe TCC or cparser/cproc areen't, but the world it's full of stuff outside of C99.
  - bradain 1y ago
    Yup, very familiar with SBCL. But the truth is, to get SBCL to the point where it's anywhere near the realm of C for performance there's a ton of work that the compiler has to do that GCC simply doesn't. Escape analysis to work out when heap allocations can be avoided, type inference to work out when dynamic type checks can be omitted / fixnum math can be used instead of generic math, when functions can be linked directly instead of dynamically dispatched, when functions are pure to allow for more flexible optimizations with evaluation order, etc. Scheme adds even more complexity despite being a far smaller language than common lisp. Reified continuations massively complicate any optimzation and so does automatic lisp-1 to lisp-2 conversion, which has a bunch of caveats making it much trickier than it seems. Add on the fact that scheme lets you overwrite core primitive operations like car/cdr and there just isn't really any ground to stand on to prove anything about the code at all. I have no idea how guile scheme runs as fast as it does. GCC on the other hand is coming from a much better point of view: C is statically typed with full type signatures on every function, argument and variable, so you can safely eliminate all runtime type-checking and arity-checking. There's no garbage collection, so you don't need that. functions can't be redefined, and all must be declared before being used so you don't need a mechanism for dynamic dispatch, there's no closures so you don't need to perform any lambda lifting or closure conversion, you don't need the compiler or the interpreter available at runtime to handle calls to eval, loops are clearly marked and easy to optimize (vs lisp using tag-body and scheme using widespread recursion with TCO), fast iteration of lists in lisp requires the compiler to prove that it can safely eliminate a null check and C just doesn't do bounds checks, and so on. There's an endless of list of reasons why it's easier to generate near-optimal assembly from C and why it's very hard to do so from lisp. A simple C compiler will produce far, far faster code than a simple lisp compiler.
binary132 1y ago
I think you would find that the primitives emacs lets you compose are not so different from the primitives bash lets you compose, just more syntactic and less, you know, clunky. :)
- anthk 1y ago
  Die hard Unix users won't use Bash. Ksh maybe, and nvi, with tools like indent, entr to check the project directories and run simple makefiles (no, not gmake): git://bitreich.org/english_knight . Bash it's too bloated, it can even do TCP/IP. Netcat can do that; or even Gawk in that case. On Unix philosophy and Lisp, Forth shares a lot of that with decomposiing tools into words instead functions and word chaining instead of pipes.
  - binary132 1y ago
    “shell” would have been the right word to use instead of “bash”, but it’s immaterial to the point.
setopt 1y ago
> now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time. I used to feel the same, after using Linux and Vim for 15 years. But then I switched to Emacs 6 years ago; initially as an experiment, but I couldn’t go back to Vim after trying Org-mode and other packages. Now my perspective has changed. Emacs at its core is not one program, in a sense. It is a Lisp interpreter with a GUI, that ships with thousands of ready-to-use Elisp programs that share common conventions for user interfaces, key bindings, extensions, and configuration. But you don’t run all those programs at once, only the ones you need, and the rest of the “bloat” is not used. So in that sense it does feel more like an operating system than a program, in a good way. But Emacs itself is modular in a way similar to Unix. Just that instead of being modular in the sense of many executables exchanging text streams, it is modular in the sense of many Elisp programs passing lists or buffers around. The Unix philosophy implemented at another layer of abstraction, in a sense. EDIT: Dired mentioned here is a good example: It is a file manager implemented as a separate "Elisp program" that communicates with coreutils under the hood.

chungy 1y ago

Emacs, and GNU at large, never cared for Eric Raymond's idea of "do one thing and one thing only" being the Unix way. They freely make large do-everything programs.

JCattheATM 1y ago
What are some other examples of them doing so aside from Emacs?

bradain 1y ago

Emacs isn't really a follower of the unix philosophy since it's more a hold-over from the world of lisp machines. Emacs also eschews the "everything is a file" philosophy of unix (programs in emacs are just lisp functions) and the idea of storing / transmitting data as plain text, instead using lisp data structures to do that. Lisp itself is kind of antithetical to the unix philosophy too when compared with C. Lisp is presents an extremely simple, totally consistent core that is extremely difficult to implement efficient compilers for. C on the other hand was designed from the outset with the goal of being easy to write compilers for. Requirements for having function prototypes ahead of uses, having all variables declared at the top of a function, etc were done to make it easier to implement. Almost a perfect example of worse is better, really. Check out the unix hater's handbook if you haven't, that sums up pretty nicely the world that emacs hails from.

anthk 1y ago
Did you check SBCL? It's pretty fast. On easy compiler, GCC and Clang are nightmare. Maybe TCC or cparser/cproc areen't, but the world it's full of stuff outside of C99.
- bradain 1y ago
  Yup, very familiar with SBCL. But the truth is, to get SBCL to the point where it's anywhere near the realm of C for performance there's a ton of work that the compiler has to do that GCC simply doesn't. Escape analysis to work out when heap allocations can be avoided, type inference to work out when dynamic type checks can be omitted / fixnum math can be used instead of generic math, when functions can be linked directly instead of dynamically dispatched, when functions are pure to allow for more flexible optimizations with evaluation order, etc. Scheme adds even more complexity despite being a far smaller language than common lisp. Reified continuations massively complicate any optimzation and so does automatic lisp-1 to lisp-2 conversion, which has a bunch of caveats making it much trickier than it seems. Add on the fact that scheme lets you overwrite core primitive operations like car/cdr and there just isn't really any ground to stand on to prove anything about the code at all. I have no idea how guile scheme runs as fast as it does. GCC on the other hand is coming from a much better point of view: C is statically typed with full type signatures on every function, argument and variable, so you can safely eliminate all runtime type-checking and arity-checking. There's no garbage collection, so you don't need that. functions can't be redefined, and all must be declared before being used so you don't need a mechanism for dynamic dispatch, there's no closures so you don't need to perform any lambda lifting or closure conversion, you don't need the compiler or the interpreter available at runtime to handle calls to eval, loops are clearly marked and easy to optimize (vs lisp using tag-body and scheme using widespread recursion with TCO), fast iteration of lists in lisp requires the compiler to prove that it can safely eliminate a null check and C just doesn't do bounds checks, and so on. There's an endless of list of reasons why it's easier to generate near-optimal assembly from C and why it's very hard to do so from lisp. A simple C compiler will produce far, far faster code than a simple lisp compiler.

binary132 1y ago

I think you would find that the primitives emacs lets you compose are not so different from the primitives bash lets you compose, just more syntactic and less, you know, clunky. :)

anthk 1y ago
Die hard Unix users won't use Bash. Ksh maybe, and nvi, with tools like indent, entr to check the project directories and run simple makefiles (no, not gmake): git://bitreich.org/english_knight . Bash it's too bloated, it can even do TCP/IP. Netcat can do that; or even Gawk in that case. On Unix philosophy and Lisp, Forth shares a lot of that with decomposiing tools into words instead functions and word chaining instead of pipes.
- binary132 1y ago
  “shell” would have been the right word to use instead of “bash”, but it’s immaterial to the point.

setopt 1y ago

> now after using linux for 20 something years, the fact that it can do everything just seems so antithetical to the unix way...even if I could see myself using it, the idea of being so dependent on one app for so much seems so weird to me these days. Guess I'll be sticking with vim and various cli tools until the end of time. I used to feel the same, after using Linux and Vim for 15 years. But then I switched to Emacs 6 years ago; initially as an experiment, but I couldn’t go back to Vim after trying Org-mode and other packages. Now my perspective has changed. Emacs at its core is not one program, in a sense. It is a Lisp interpreter with a GUI, that ships with thousands of ready-to-use Elisp programs that share common conventions for user interfaces, key bindings, extensions, and configuration. But you don’t run all those programs at once, only the ones you need, and the rest of the “bloat” is not used. So in that sense it does feel more like an operating system than a program, in a good way. But Emacs itself is modular in a way similar to Unix. Just that instead of being modular in the sense of many executables exchanging text streams, it is modular in the sense of many Elisp programs passing lists or buffers around. The Unix philosophy implemented at another layer of abstraction, in a sense. EDIT: Dired mentioned here is a good example: It is a file manager implemented as a separate "Elisp program" that communicates with coreutils under the hood.