9 ms·

Unix as a tool forge and how Emacs fits in Unix philosophy

160 points by ashton314 4y ago

pjmlp 4y ago
Emacs is a survivor from the days of Lisp Machines, hardly a UNIX. "Evolution of Emacs Lisp" https://dl.acm.org/doi/abs/10.1145/3386324 https://dl.acm.org/doi/abs/10.1145/3386324 Also the UNIX "philosophy" besides its quote on a book, has been hardly a thing on commercial UNIXes.
- anthk 4y ago
  I was about to say that. Emacs not just the LISP machines. Emacs' comes from ITS, an OS praised by RMS, basically the anithesis of Unix. Everything was hackable and shareable. No perms. The closest in philosophy may be Guix(SD), but, for that, the Unix utilities should be converted into optional tools and make Scheme both the command line prompt shell, the configuration tool and the API.
  - thrown_22 4y ago
    I've ran chsh on top of a (virtual) Guix(SD) installation. It was rather nice but is still _not_ a lisp machine: https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
- AnimalMuppet 4y ago
  > Emacs is a survivor from the days of Lisp Machines, hardly a UNIX. So? Did the author claim otherwise? Not that I could see. Does the OS of origin negate any of the author's claims about Emacs? No, it doesn't. Emacs on Unix gave the author a tool that fit their workflow and their mindset. Who cares what OS it originated on? > Also the UNIX "philosophy" besides its quote on a book, has been hardly a thing on commercial UNIXes. The UNIX philosophy, as quoted by the author, was supported by every commercial OS I have ever seen. (They added some other stuff, but they all provided the environment where the philosophy could play out well.)
  - pjmlp 4y ago
    Given the architecture of commercial UNIXes, and the plethora of options in every command, hardly.
  - anthk 4y ago
    No. Emacs' a huge REPL with zillions of ELISP modules for lots of cases. Emacs and its grandpa ITS (and Emacs for ITS) are very different beasts. Get SIMH and emulate ITS on it. https://gunkies.org/wiki/Installing_ITS_on_SIMH https://gunkies.org/wiki/Installing_ITS_on_SIMH
- whartung 4y ago
  The funny thing is that I put vi more in the "UNIX Philosophy" camp. Specifically, as a user of vi, especially with normal vi (vs vim), a routine workflow for me is !command some block of text, or the entire file to some utility or another. And the idea here is that with little effort, the entirety of the UNIX environment (at least the CLI tools environment) is at my beck and call. I've munged gobs of text through most any utility imaginable. I've use vi as an interactive pipeline. Running data through one sequence, then running it through another, or a 3rd. It's like an interactive pipeline debugger with undo. It's not that emacs can not do it, of course it can. You can run a region through a shell command as easily as anything. But, folks don't. Rather they rely on the extensive, emacs universe to solve those problems. There's lisp for that. Like the Java and JavaScript eco-systems, where "everything" gets rewritten into that world, the drive has been to port the essential utilities into the whole of emacs, rather than having it work with the system surrounding it. There's all sorts of good reasons for this, but at the same time, all of those routines and such are cut off from "unix". While its straightforward to leverage grep, sort, awk, et al from within emacs, it's less so the other way around. I'm sure it's possible, but it's not trivial. In a world of composite solution development, a monolith stands out because it acts more as an unscalable tower rather than a thing to touch for enlightenment.
  - anthk 4y ago
    nvi, entr, xargs, awk, sed, perl...
  - 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.
    - 4y ago
- bigbillheck 4y ago
  That paper is about 'emacs lisp', not emacs itself, which came out of systems running on various PDPs.
  - pjmlp 4y ago
    Yes, and most of them predate UNIX.
ok_dad 4y ago
I use VSCode right now, with lots of little extensions to do stuff like lint my code, format my code, color my code, highlight TODO and FIXME comments, 3-way merges, debugging with conditional breakpoints and watches and stuff, etc. How do I get started using Emacs, if I wanted to use this awesome-sounding tool, while still being friendly to the fact that I have to get stuff done and still need the tools I mentioned above? (Also, how to have my cake and eat it, too.) I am sure the Emacs community has built everything under the sun, but is it as easy to setup and easy to find as VSCode? I really want to know how I can transition from using VSCode to Emacs, because I'm starting to realize that VSCode is always going to be a "product" of a BigCo and will continue to add anti-features, tracking, and other stuff that I don't want. I'm also starting to realize that I want to be a bit more strict about my open source software usage, and try to support communities rather than coprorations.
- vincent-manis 4y ago
  To get started with Emacs: (1) install it, either from a package repository or from www.gnu.org/software/emacs; (2) start it up (3) type Control-H t to run the tutorial. Those new to Emacs might prefer to use a customized distribution such as Doom Emacs, but the official Emacs system is quite usable. Don't expect to become an Emacs Master quickly, but doing these 3 steps will get you to the point where you can use Emacs for basic text editing. Emacs comes with lots of documentation, both on the core system and on the many packages it includes, but you can defer reading it until you are comfortable with the basics. The two hurdles you'll need to overcome are: (1) the antique terminology, so “window” doesn't mean what you might expect it to, and (2) the key bindings, which don't match up with more modern systems. (1) is something you just have to get used to, while (2) is infinitely flexible. A vi user might prefer Doom Emacs or Spacemacs, which come with vi-compatible key-bindings; I'm not aware of something similar for the VSCode user. As you become more comfortable with Emacs, you will be able to make your own key bindings.
  - ok_dad 4y ago
    Thanks! That actually is what I found in the past, that (1) is hard to get through in order to setup an environment with the cool tools I want to use, and (2) is hard because I'm used to VSCode bindings. I think this time, though, I'm going to stage my use of Emacs because you gave me a good idea: > doing these 3 steps will get you to the point where you can use Emacs for basic text editing So, I'm going to replace my use of VSCode for text editing with Emacs for a while to start learning how to work with it, just not code stuff yet, and I'll replace my keybindings in VSCode with Emacs keybindings since VSCode is super easy to find extensions for and there happens to be a few "Emacs keybinding" extensions. Thanks for the tips, I also didn't know about `Ctrl+H t` and so I'll try that out, too! I'm actually pretty excited, I've had a ton of issues with VSCode updating the way they do things recently causing my workflows to get fucked up and have to change. I doubt I'll have that issue with Emacs!
jrm4 4y ago
This is an incredibly underutilized idea. It still feels like there's ample room for interoperability in the realm of "I write a short piece of code for someone I'm working with, and then they take it and use it for something else" in a way that could be very specific to one project. I'd venture to say that essentially no one thinks like this, but there's no good reason they shouldn't?
- alkonaut 4y ago
  Isn't that what package managers in programming languages do? E.g. if I write a "left pad" library and put it on npm, then it can compose into someone elses program and left pad their strings.
namaria 4y ago
I don't think you need to shoehorn every piece of software you like into one worldview. It's OK to like two different things. Contradiction is a fact of nature when discourse is linear but reality is anything but. Unix philosophy was amazing in the 70s, modern linuxes are great work environments now, EMACS is super cool, vim is a great little piece of text editing beauty. One thing is clear tho, Windows users have a severe case of Stockholm syndrome.
- pjmlp 4y ago
  I love my Stockholm syndrome on .NET, Visual Studio, Delphi, C++ Builder, PowerShell, DirectX.
  - namaria 4y ago
    Good on you, I will keep chugging along with bash and go in the server rooms.
- eternityforest 4y ago
  I don't think anyone has Stockholm syndrome. Windows works very well at basic chromebook like tasks and runs proprietary software well, most of the time. Linux is just now patching up the last few big issues and fully catching up to Windows, and it's really only Mint and a few others that have windows parity. If you try any distro a linux enthusiast will probably recommend, like Manjaro, you can generally expect to fuss with stuff more than you would on windows by far. And Mac is tightly tied to their non desktop metaphor UI that relies entirely on idiomatic gestures. Windows isn't great, but it works and it's easy.
  - namaria 4y ago
    Please, Ubuntu is super easy to use. Windows has been putting ads inside your desktop environment and yeah no-one is gonna move on from it because they love to be captive to that ecosystem. Textbook Stockholm syndrome.
ashton314 4y ago
Hi all, author here. Thanks for all the comments. I was not expecting to get on the front page with this little thought I had in the shower this weekend! Someone reached out to me with the following links, and I thought they'd be good to share: - https://amodernist.com/texts/emacs-unix.html https://amodernist.com/texts/emacs-unix.html - https://protesilaos.com/codelog/2021-09-22-live-stream-emacs-unix/ https://protesilaos.com/codelog/2021-09-22-live-stream-emacs... - https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-the-unix-philosophy.html https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-th... I haven't watched the video by Prot yet, but I felt like these all belonged here to add to the conversation.
BeetleB 4y ago
The article doesn't really do justice to the composability - it provides little to no examples. So I'll try to provide some: Emacs has a lot of functionality on displaying email, handling attachments, etc. This made it almost trivial for notmuch[1] to make a frontend for their tool. If you think about it, notmuch is merely a stand alone indexer. But they quickly made a full blown email client in Emacs revolving around notmuch by borrowing most of the functionality from packages like Gnus, etc. magit has a neat menu based interface. Now many other packages make use of its interface even though they have nothing to do with git. There are multiple completion frameworks, and it's always gratifying to utilize one of them for your own needs. As an example, I wanted to keep a directory of contacts. I used org-roam to create a node for each contact, and freely put any information I wanted in there (notes about the person, etc). However, I sometimes keep meeting minutes at work (in org mode) and whenever I mention a person, I want a link to his/her contact page. So I hacked up some elisp functions to: 1. Insert a new person (and return a link to him/her) 2. Select an existing person (this is where using a completion framework comes in). Think of all the different pieces I used: 1. Org mode 2. Org-roam 3. A completion framework like vertico to show me only nodes that are people, and not all my notes nodes. 4. Calendar functionality to specify times/dates (really I'm using the functionality in org mode, which builds on the Emacs calendar functionality). Basically I built a minutes taking tool + contacts management by using various components of packages. It was not a lot of code - perhaps 1-2 screenfuls. I once had a directory with a lot of video files. I wanted to share some with friends, but needed to go through each one to decide if it's relevant to them. I wrote some simple elisp that, within dired (Emac's file manager), when I hit Enter on an mp4 file, would play the file using mplayer. If I wanted to share it, with another keybinding, it would put a link to the file in a particular org document. This is a typical example, of utilizing several different Emacs packages to achieve a custom task. [1] https://notmuchmail.org/ https://notmuchmail.org/
- ashton314 4y ago
  Great example! Yes, the way org-mode and the various email systems play nicely together is sheer beauty. Nothing like it.
- joeman1000 4y ago
  It’s a playground for text. If you dream of a feature you want and your elisp is decent, the dream can become reality. It’s a beautiful big mess of features that mostly inter-operate. It feels like you can create ‘emergent behaviour’ when you compose the features. I started off in emacs just using it to take notes at uni. I wanted to get inline previews of LaTeX equations. Previously I was doing the old ‘markdown written in vim converted to pdf via pandoc’, but I knew something was just.. off. It was a slog to add pictures to notes, I couldn’t render my equations easily, exporting was cumbersome and not the way I wanted it to look… I wanted to do MORE with my notes, have them feel like live documents, not just plaintext in a terminal. I stumbled across doom emacs 2 years ago, knowing only a paltry bit of python. Picking emacs on that day was one of the greatest choices in my whole life, without any exaggeration. It was very daunting to dive into this big, alien world and ingest so much information (conventions, package names, functions, …). I just kept finding myself amazed that, for someone who prefers to limit mouse usage, emacs contains the absolute best experience in: - note taking - document creation (org, ox) - literate programming (org-babel) - pdf viewing and interaction (pdf-tools) - time management and planning (org) - version control (vc, magit) - desktop RPN calculation (calc) - PKM (roam, denote) This was just a Cambrian explosion of creativity for me. Any number of these killer features were composable in whatever way I fancied. I was no longer held back by the poor interfaces and segregated nature of literally every other piece of software I had used in my life previously. I mentioned that I only knew a bit of python when starting… the barrier to entry for most languages drops sharply every time you increase your emacs skill. Language major-modes are the distilled knowledge of thousands of man-hours in any particular machine language. Using these (none of which I’ve even mentioned in my list above), I’ve been able to learn (on my own, while studying civil engineering): - emacs lisp - Julia - Common Lisp - Scheme - Racket - APL & J - JavaScript - R - (a few more at a cursory level) I’ve interviewed at a few engineering firms based on these skills and they’ve all asked me “how did you go about learning all of these things?”, to which I couldn’t just reply “emacs”, but I really should have. I actually was picked out of the pile of resumes/cover letters because of the presentation and formatting (LaTeX pdf export from org). I was then offered an internship because of my skills gained by using emacs for a few years. I don’t exaggerate by saying it changed my life. Anyone reading this with any spark of interest: please put aside any notions you have about emacs and just give it a chance.
DonHopkins 4y ago
This document describes UniPress Emacs 2.20, the Unix version written in C by James Gosling and distributed by UniPress (who RMS referrers to as "Evil Software Hoarders"), based on the MockLisp extension language. Version 2.20 included multi-window support for SunView, X-Windows, and the NeWS window system. The document goes on to describe the future plans for SoftWire (a networked PostScript interpreter like NeWS but for managing text file and streams and sub-processes instead of drawing graphics), which UniPress developed but by never released. UniPress Emacs Newsletter, February 1988: What is Emacs? https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf
dale_glass 4y ago
That's great, but I think sometimes "Unix Philosophy" looks too much like a religion. Programs are tools, and if they do the work they need to do, who cares if they comply with some ancient ideal or not? Yes, certainly composability is a worthy feature to have if it fits, but sometimes it's not there and nobody cares because the tool still does the job. I'm also of the view of that the ideal might be almost obsolete in its original form. Yeah, "grep | awk | sort | uniq" style chains are neat and all, but in modern times they're actually quite inflexible. Modern data is likely to have a complex structure many of those tools are ill-equipped to deal with. Most any time I write anything of even slight complexity, I end up doing it in Perl or Python, and it works almost exactly the way the same code under Windows would. I've also got to admit that Microsoft got a leg up here with PowerShell, because rather than holding up to tradition from the 70s, they applied new modern thought to the problem and came up with something better. I think it's unfortunate that Linux has acquired a considerable amount of traditionalism, because that risks making it slow to adapt and improve.
- every 4y ago
  Unlike most religions, the Unix Philosophy actually produces positive and tangible results...
  - legends2k 4y ago
    Care to substantiate your claim with examples other than the usual, now-old coreutils, binutils, etc.?
    - every 4y ago
      https://every.sdf.org/US_ASCII/Geekish/various/knuth-macilroy.txt https://every.sdf.org/US_ASCII/Geekish/various/knuth-macilro...
avgcorrection 4y ago
The Unix Philosophy as commonly invoked is rigged. You are apparently not allowed to implement the Philosophy on top of (as an application) Unix. Only by using the OS—which gives you the options of Unix, and… Windows?—are you practicing the philosophy. But hold on. What if you don’t have a lisp machine lying around? What if Unix, or Unix-likes, or asterisk-nix is all you’ve got? Well it seems you have to implement your own lisp platform and run it on those icky Unixen. Great, what could be more composable than an application which can be extended using Lisp, where key presses and functions are interchangeable? And now you get to communicate with your “small programs” on your Lisp platform. But then bam, you’re disqualified. Because now people have decided—for arbitrary reasons—that you have moved one level too far up.
- a9h74j 4y ago
  One gloss on comparative philosophy: *nix: Extendable command line (via C, etc) plus shell scripts Emacs: Extendable command line (via Lisp) plus keymaps
  - Siira 4y ago
    Emacs can shell out just fine. Even the opposite is possible: You can ask a running emacs server to eval arbitrary code. I use both frequently.
jonjacky 4y ago
One of the original Unix creators, Doug McIlroy, credited with inventing pipes, wrote in [1]: "... I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. Emacs and vi raised that number to a high power ... ... Unix was born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities. But evolution, including the evolution of Unix, does not work that way. ..." The editors favored by the original Unix guys are ed, sam, and acme. 1. https://minnie.tuhs.org/pipermail/tuhs/2014-August/006506.html https://minnie.tuhs.org/pipermail/tuhs/2014-August/006506.ht...
- taeric 4y ago
  This is somewhat silly. First, the mystery chords for the terminal only grew. And... Is kind of the reason to use a different editor. Second, adding acme as a preferred editor throws the conceit by introducing the mouse to the chords. I fully grant that chords with the mouse probably add a lot, especially after training. I struggle to see how "small means" can lead you to any one editor over another, though.
- return_to_monke 4y ago
  But you can use these chords inside the editor's terminal (for example (n)vim's :term), so it's easier to scroll back, search stuff and copy-paste, for example
- guenthert 4y ago
  I can see that emacs (predating Unix) doesn't fit into the Unix philosophy (and I don't see a reason why it should -- it's first and foremost an editor, not a system tool), but "The editors favored by the original Unix guys are ed, sam, and acme." doesn't make any sense. vi was the VIsual interface to ed, so ed has all the mystery chords, just expects you to operate blindly.
  - jonjacky 4y ago
    Some of the original Bell Labs Unix people have a very austere view of the Unix philosophy. In their view, it all started to go wrong -- Unix began to depart from the founding principles -- as early as 1978. In their view, Berkeley Unix does not follow their Unix philosophy -- they don't like network sockets, for example, whose design was mostly imported from some earlier non-Unix system (maybe Tenex?). Some of this attitude appears in Rob Pike's 'Good, Bad and Ugly' talk from 2001 [1]. He says the early Unix tools approach had, by then, already been replaced for most users by big do-everything programs: Emacs, Perl, browsers... 1. http://herpolhode.com/rob/ugly.pdf http://herpolhode.com/rob/ugly.pdf
somedudetbh 4y ago
It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" by people who presumably use Unix? Maybe it's a philosophy like "Don't do sins" is a philosophy of Christians? More of an aspiration than an actual practice? I can't really think of any Unix programs in common use that do one thing well. Inevitably, they grow to redundantly include features that other programs have. If anything can be said to be the actual lived Unix philosophy it's probably something like: 1) Try to make your programs communicate using text, where the 'record' is separated by a newline. 2) If you have a choice between making a program a little more friendly to use, or making it's text communication a little simpler to compose with, go with the second option. E.g. if there's nothing to output when a program runs don't output "Nothing to output", just output nothing. I don't think Emacs really fits with the unix philosophy, whether my version or the common version, at all. One of the main things I like about emacs is that it's like a vision of an alternate computing universe, where we assume that we're operating in a giant image that's meant to be programmed and customized all the time. What if most of your work was done in a LISP repl with a bunch of UI tweaks? It's like using a research project from a 70s or 80s "Future of Computing" lab that never actually shipped, except it did ship. It feels like it should have a lightpen attached. I don't even really think it's particularly practical to use emacs at this point, I just like this vibe and reminder that nothing about the way we use computers was inevitable so much that I stubbornly still use it.
- __d 4y ago
  The "Unix philosophy" is pretty debased in a modern Linux system. A BSD still has echoes of the original, but to get the pure experience, you should probably play with a Plan9 (maybe 9front), where the "one thing, well" bit is still taken seriously.
- badsectoracula 4y ago
  > It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" [...] If anything can be said to be the actual lived Unix philosophy it's probably something like: 1) Try to make your programs communicate using text, where the 'record' is separated by a newline. [..etc..] The Unix Philosophy isn't just about writing programs that do one thing well (and FWIW it isn't really a philosophy or dogma, it is more of a guideline/goal), there are a bunch of things. The "write programs that do one thing well" is just one ways to think about it. The most common set of goals is: 1. Write programs that do one thing and do it well. 2. Write programs to work together. 3. Write programs to handle text streams, because that is a universal interface. But there is really more to it as can be seen in the Wikipedia page[0], like ESR's 19 rules and Mike Gancarz (who wrote the "The UNIX Philosophy" book from his experiences) 9 tenets (three of the most common being using flat text files for data, avoiding captive user interfaces as that makes composition harder and making programs act as filters). Really at the very core is the goal to make programs that can be glued together with other programs (often via scripts) to perform tasks and communicate in ways (pretty always via text) that humans can see so that they can stitch them together even if they know nothing about each other (for example even if two or more programs they use different formats for their input/output, since they use text, other common tools like grep, awk, etc can be used as filters/pipes directly or via scripts to connect them together). This is where the "do one thing" comes from: if your program acts as a filter and/or communicates just via text, there is no need to complicate your program by adding functionality that another program can provide since a user can simply glue the two together. For example if you have some program that returns the values of some sensors you don't need to add search or filtering functionality since one can use grep and awk for that. [0] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
deleted 4y ago
[deleted]
bitwize 4y ago
Small, composable "Unix philosophy" programs need a substrate in order to work well, and that substrate can be heavyweight. The Unix kernel itself with its process and I/O model is one example (though Plan 9 may be considered an experiment in just how minimal that substrate can be while supporting the essential features of the model). The shell allows linking these programs together in a way that's relatively user-friendly, making the toolkit of composable programs accessible. Relatedly, the X server is a substrate that allows small modular programs to coordinate in different ways, composing to form a graphical desktop environment. I think Emacs on Unix is another such substrate. In a way, it's a sort of super-shell that can not only allow the user to compose Unix programs as with the shell, but to capture their input and output in buffers for further editing and processing. The ability to capture text, whether from files, programs, or network connections, edit it in a buffer, and script any operation with Lisp makes Emacs a tremendously powerful tool in its own right and an easily configurable coordinator for your other tools, with enough power to let you put a custom UI over them for smooth, flow-conducive access at your fingertips.
- pjmlp 4y ago
  Inferno was an even better experiment, the kernel and Limbo VM had a minimal attack surface, everything else was based on the same principles as Plan 9 and dynamically loadable modules written in Limbo.
cranium 4y ago
One could argue that Emacs is a lisp VM specialized for text edition, and in that sense does only one thing and does it well.
larsbrinkhoff 4y ago
"How Emacs fits inside of Unix philosophy" I see this time and again. Why is there a need to fit Emacs inside the Unix philosophy? I think it's perfectly fine if it doesn't.
- TeMPOraL 4y ago
  For the same reason certain religion known for door-to-door proselytism insists on being classified as Christianity: because it recruits from other Christian groups. Similarly, Emacs recruits users mainly from software devs and Linux users, many of whom have almost religious belief in Unix philosophy.
xenodium 4y ago
While I'm no elisp expert, I know enough to glue all sorts of utils. It enables scratching my own itches, often resulting in accessible workflows that do exactly what I mean. Some recent examples: Hey Emacs, where did I take that photo? - https://xenodium.com/hey-emacs-where-did-i-take-that-photo https://xenodium.com/hey-emacs-where-did-i-take-that-photo Emacs: Open with macOS app - https://xenodium.com/emacs-open-with-macos-app https://xenodium.com/emacs-open-with-macos-app Emacs: Reveal in macOS Finder (DWIM style) - https://xenodium.com/emacs-reveal-in-finder-dwim-style https://xenodium.com/emacs-reveal-in-finder-dwim-style Seamless command-line utils - https://xenodium.com/seamless-command-line-utils https://xenodium.com/seamless-command-line-utils
James_K 4y ago
The UNIX philosophy is redundant. The only unique part of it is to use text for everything, which isn't a very good piece of advice. It only exists to cover for the mistakes of UNIX. The bulk of it is saying that you should apply the same design principals you would on the inside of a program to the external interface of it. The irony here is that people only treat these situations differently because UNIX forces programs to interact through limited means (a single function which accepts an array of strings as its arguments). If UNIX allowed programs to represent themselves as modules of functions which act on datastructures richer than a string, it would be obvious to everyone that they should apply good programming principals to these modules. Case in point: Emacs. Its programs are modular, so it needs no grand philosophy telling programmers to apply the well known practices of good design. The `find' utility is the exact sort of thing that the UNIX philosophy warns against. It contains huge amounts of duplicate functionality; I believe the version installed on my system takes more than a hundred flags. No such functions exist in Emacs, because it would never occur to someone that they should write a function with over a hundred keyword arguments to do something as basic as file handling. The advice in the UNIX philosophy exists only to combat the issues that UNIX creates, which is why I am so confused by the fact that so many people are reverent to it. They act as though UNIX invented simplicity or good design, as though the application thereof is something special rather than what should be the default for any competent programmer. I can only speculate why this happens. My personal view is that UNIX has locked us into systems that don't follow its own philosophy. People come to view this failure as the default, so any instance of good design is remarkable.

160 points by ashton314 4y ago

Emacs is a survivor from the days of Lisp Machines, hardly a UNIX. "Evolution of Emacs Lisp" https://dl.acm.org/doi/abs/10.1145/3386324 https://dl.acm.org/doi/abs/10.1145/3386324 Also the UNIX "philosophy" besides its quote on a book, has been hardly a thing on commercial UNIXes.

anthk 4y ago
I was about to say that. Emacs not just the LISP machines. Emacs' comes from ITS, an OS praised by RMS, basically the anithesis of Unix. Everything was hackable and shareable. No perms. The closest in philosophy may be Guix(SD), but, for that, the Unix utilities should be converted into optional tools and make Scheme both the command line prompt shell, the configuration tool and the API.
- thrown_22 4y ago
  I've ran chsh on top of a (virtual) Guix(SD) installation. It was rather nice but is still _not_ a lisp machine: https://www.youtube.com/watch?v=o4-YnLpLgtk https://www.youtube.com/watch?v=o4-YnLpLgtk
AnimalMuppet 4y ago
> Emacs is a survivor from the days of Lisp Machines, hardly a UNIX. So? Did the author claim otherwise? Not that I could see. Does the OS of origin negate any of the author's claims about Emacs? No, it doesn't. Emacs on Unix gave the author a tool that fit their workflow and their mindset. Who cares what OS it originated on? > Also the UNIX "philosophy" besides its quote on a book, has been hardly a thing on commercial UNIXes. The UNIX philosophy, as quoted by the author, was supported by every commercial OS I have ever seen. (They added some other stuff, but they all provided the environment where the philosophy could play out well.)
- pjmlp 4y ago
  Given the architecture of commercial UNIXes, and the plethora of options in every command, hardly.
- anthk 4y ago
  No. Emacs' a huge REPL with zillions of ELISP modules for lots of cases. Emacs and its grandpa ITS (and Emacs for ITS) are very different beasts. Get SIMH and emulate ITS on it. https://gunkies.org/wiki/Installing_ITS_on_SIMH https://gunkies.org/wiki/Installing_ITS_on_SIMH
whartung 4y ago
The funny thing is that I put vi more in the "UNIX Philosophy" camp. Specifically, as a user of vi, especially with normal vi (vs vim), a routine workflow for me is !command some block of text, or the entire file to some utility or another. And the idea here is that with little effort, the entirety of the UNIX environment (at least the CLI tools environment) is at my beck and call. I've munged gobs of text through most any utility imaginable. I've use vi as an interactive pipeline. Running data through one sequence, then running it through another, or a 3rd. It's like an interactive pipeline debugger with undo. It's not that emacs can not do it, of course it can. You can run a region through a shell command as easily as anything. But, folks don't. Rather they rely on the extensive, emacs universe to solve those problems. There's lisp for that. Like the Java and JavaScript eco-systems, where "everything" gets rewritten into that world, the drive has been to port the essential utilities into the whole of emacs, rather than having it work with the system surrounding it. There's all sorts of good reasons for this, but at the same time, all of those routines and such are cut off from "unix". While its straightforward to leverage grep, sort, awk, et al from within emacs, it's less so the other way around. I'm sure it's possible, but it's not trivial. In a world of composite solution development, a monolith stands out because it acts more as an unscalable tower rather than a thing to touch for enlightenment.
- anthk 4y ago
  nvi, entr, xargs, awk, sed, perl...
- 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.
  - 4y ago
bigbillheck 4y ago
That paper is about 'emacs lisp', not emacs itself, which came out of systems running on various PDPs.
- pjmlp 4y ago
  Yes, and most of them predate UNIX.

ok_dad 4y ago

I use VSCode right now, with lots of little extensions to do stuff like lint my code, format my code, color my code, highlight TODO and FIXME comments, 3-way merges, debugging with conditional breakpoints and watches and stuff, etc. How do I get started using Emacs, if I wanted to use this awesome-sounding tool, while still being friendly to the fact that I have to get stuff done and still need the tools I mentioned above? (Also, how to have my cake and eat it, too.) I am sure the Emacs community has built everything under the sun, but is it as easy to setup and easy to find as VSCode? I really want to know how I can transition from using VSCode to Emacs, because I'm starting to realize that VSCode is always going to be a "product" of a BigCo and will continue to add anti-features, tracking, and other stuff that I don't want. I'm also starting to realize that I want to be a bit more strict about my open source software usage, and try to support communities rather than coprorations.

vincent-manis 4y ago
To get started with Emacs: (1) install it, either from a package repository or from www.gnu.org/software/emacs; (2) start it up (3) type Control-H t to run the tutorial. Those new to Emacs might prefer to use a customized distribution such as Doom Emacs, but the official Emacs system is quite usable. Don't expect to become an Emacs Master quickly, but doing these 3 steps will get you to the point where you can use Emacs for basic text editing. Emacs comes with lots of documentation, both on the core system and on the many packages it includes, but you can defer reading it until you are comfortable with the basics. The two hurdles you'll need to overcome are: (1) the antique terminology, so “window” doesn't mean what you might expect it to, and (2) the key bindings, which don't match up with more modern systems. (1) is something you just have to get used to, while (2) is infinitely flexible. A vi user might prefer Doom Emacs or Spacemacs, which come with vi-compatible key-bindings; I'm not aware of something similar for the VSCode user. As you become more comfortable with Emacs, you will be able to make your own key bindings.
- ok_dad 4y ago
  Thanks! That actually is what I found in the past, that (1) is hard to get through in order to setup an environment with the cool tools I want to use, and (2) is hard because I'm used to VSCode bindings. I think this time, though, I'm going to stage my use of Emacs because you gave me a good idea: > doing these 3 steps will get you to the point where you can use Emacs for basic text editing So, I'm going to replace my use of VSCode for text editing with Emacs for a while to start learning how to work with it, just not code stuff yet, and I'll replace my keybindings in VSCode with Emacs keybindings since VSCode is super easy to find extensions for and there happens to be a few "Emacs keybinding" extensions. Thanks for the tips, I also didn't know about `Ctrl+H t` and so I'll try that out, too! I'm actually pretty excited, I've had a ton of issues with VSCode updating the way they do things recently causing my workflows to get fucked up and have to change. I doubt I'll have that issue with Emacs!

jrm4 4y ago

This is an incredibly underutilized idea. It still feels like there's ample room for interoperability in the realm of "I write a short piece of code for someone I'm working with, and then they take it and use it for something else" in a way that could be very specific to one project. I'd venture to say that essentially no one thinks like this, but there's no good reason they shouldn't?

alkonaut 4y ago
Isn't that what package managers in programming languages do? E.g. if I write a "left pad" library and put it on npm, then it can compose into someone elses program and left pad their strings.

namaria 4y ago

I don't think you need to shoehorn every piece of software you like into one worldview. It's OK to like two different things. Contradiction is a fact of nature when discourse is linear but reality is anything but. Unix philosophy was amazing in the 70s, modern linuxes are great work environments now, EMACS is super cool, vim is a great little piece of text editing beauty. One thing is clear tho, Windows users have a severe case of Stockholm syndrome.

pjmlp 4y ago
I love my Stockholm syndrome on .NET, Visual Studio, Delphi, C++ Builder, PowerShell, DirectX.
- namaria 4y ago
  Good on you, I will keep chugging along with bash and go in the server rooms.
eternityforest 4y ago
I don't think anyone has Stockholm syndrome. Windows works very well at basic chromebook like tasks and runs proprietary software well, most of the time. Linux is just now patching up the last few big issues and fully catching up to Windows, and it's really only Mint and a few others that have windows parity. If you try any distro a linux enthusiast will probably recommend, like Manjaro, you can generally expect to fuss with stuff more than you would on windows by far. And Mac is tightly tied to their non desktop metaphor UI that relies entirely on idiomatic gestures. Windows isn't great, but it works and it's easy.
- namaria 4y ago
  Please, Ubuntu is super easy to use. Windows has been putting ads inside your desktop environment and yeah no-one is gonna move on from it because they love to be captive to that ecosystem. Textbook Stockholm syndrome.

ashton314 4y ago

Hi all, author here. Thanks for all the comments. I was not expecting to get on the front page with this little thought I had in the shower this weekend! Someone reached out to me with the following links, and I thought they'd be good to share: - https://amodernist.com/texts/emacs-unix.html https://amodernist.com/texts/emacs-unix.html - https://protesilaos.com/codelog/2021-09-22-live-stream-emacs-unix/ https://protesilaos.com/codelog/2021-09-22-live-stream-emacs... - https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-the-unix-philosophy.html https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-th... I haven't watched the video by Prot yet, but I felt like these all belonged here to add to the conversation.

BeetleB 4y ago

The article doesn't really do justice to the composability - it provides little to no examples. So I'll try to provide some: Emacs has a lot of functionality on displaying email, handling attachments, etc. This made it almost trivial for notmuch[1] to make a frontend for their tool. If you think about it, notmuch is merely a stand alone indexer. But they quickly made a full blown email client in Emacs revolving around notmuch by borrowing most of the functionality from packages like Gnus, etc. magit has a neat menu based interface. Now many other packages make use of its interface even though they have nothing to do with git. There are multiple completion frameworks, and it's always gratifying to utilize one of them for your own needs. As an example, I wanted to keep a directory of contacts. I used org-roam to create a node for each contact, and freely put any information I wanted in there (notes about the person, etc). However, I sometimes keep meeting minutes at work (in org mode) and whenever I mention a person, I want a link to his/her contact page. So I hacked up some elisp functions to: 1. Insert a new person (and return a link to him/her) 2. Select an existing person (this is where using a completion framework comes in). Think of all the different pieces I used: 1. Org mode 2. Org-roam 3. A completion framework like vertico to show me only nodes that are people, and not all my notes nodes. 4. Calendar functionality to specify times/dates (really I'm using the functionality in org mode, which builds on the Emacs calendar functionality). Basically I built a minutes taking tool + contacts management by using various components of packages. It was not a lot of code - perhaps 1-2 screenfuls. I once had a directory with a lot of video files. I wanted to share some with friends, but needed to go through each one to decide if it's relevant to them. I wrote some simple elisp that, within dired (Emac's file manager), when I hit Enter on an mp4 file, would play the file using mplayer. If I wanted to share it, with another keybinding, it would put a link to the file in a particular org document. This is a typical example, of utilizing several different Emacs packages to achieve a custom task. [1] https://notmuchmail.org/ https://notmuchmail.org/

ashton314 4y ago
Great example! Yes, the way org-mode and the various email systems play nicely together is sheer beauty. Nothing like it.
joeman1000 4y ago
It’s a playground for text. If you dream of a feature you want and your elisp is decent, the dream can become reality. It’s a beautiful big mess of features that mostly inter-operate. It feels like you can create ‘emergent behaviour’ when you compose the features. I started off in emacs just using it to take notes at uni. I wanted to get inline previews of LaTeX equations. Previously I was doing the old ‘markdown written in vim converted to pdf via pandoc’, but I knew something was just.. off. It was a slog to add pictures to notes, I couldn’t render my equations easily, exporting was cumbersome and not the way I wanted it to look… I wanted to do MORE with my notes, have them feel like live documents, not just plaintext in a terminal. I stumbled across doom emacs 2 years ago, knowing only a paltry bit of python. Picking emacs on that day was one of the greatest choices in my whole life, without any exaggeration. It was very daunting to dive into this big, alien world and ingest so much information (conventions, package names, functions, …). I just kept finding myself amazed that, for someone who prefers to limit mouse usage, emacs contains the absolute best experience in: - note taking - document creation (org, ox) - literate programming (org-babel) - pdf viewing and interaction (pdf-tools) - time management and planning (org) - version control (vc, magit) - desktop RPN calculation (calc) - PKM (roam, denote) This was just a Cambrian explosion of creativity for me. Any number of these killer features were composable in whatever way I fancied. I was no longer held back by the poor interfaces and segregated nature of literally every other piece of software I had used in my life previously. I mentioned that I only knew a bit of python when starting… the barrier to entry for most languages drops sharply every time you increase your emacs skill. Language major-modes are the distilled knowledge of thousands of man-hours in any particular machine language. Using these (none of which I’ve even mentioned in my list above), I’ve been able to learn (on my own, while studying civil engineering): - emacs lisp - Julia - Common Lisp - Scheme - Racket - APL & J - JavaScript - R - (a few more at a cursory level) I’ve interviewed at a few engineering firms based on these skills and they’ve all asked me “how did you go about learning all of these things?”, to which I couldn’t just reply “emacs”, but I really should have. I actually was picked out of the pile of resumes/cover letters because of the presentation and formatting (LaTeX pdf export from org). I was then offered an internship because of my skills gained by using emacs for a few years. I don’t exaggerate by saying it changed my life. Anyone reading this with any spark of interest: please put aside any notions you have about emacs and just give it a chance.

DonHopkins 4y ago

This document describes UniPress Emacs 2.20, the Unix version written in C by James Gosling and distributed by UniPress (who RMS referrers to as "Evil Software Hoarders"), based on the MockLisp extension language. Version 2.20 included multi-window support for SunView, X-Windows, and the NeWS window system. The document goes on to describe the future plans for SoftWire (a networked PostScript interpreter like NeWS but for managing text file and streams and sub-processes instead of drawing graphics), which UniPress developed but by never released. UniPress Emacs Newsletter, February 1988: What is Emacs? https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf

dale_glass 4y ago

That's great, but I think sometimes "Unix Philosophy" looks too much like a religion. Programs are tools, and if they do the work they need to do, who cares if they comply with some ancient ideal or not? Yes, certainly composability is a worthy feature to have if it fits, but sometimes it's not there and nobody cares because the tool still does the job. I'm also of the view of that the ideal might be almost obsolete in its original form. Yeah, "grep | awk | sort | uniq" style chains are neat and all, but in modern times they're actually quite inflexible. Modern data is likely to have a complex structure many of those tools are ill-equipped to deal with. Most any time I write anything of even slight complexity, I end up doing it in Perl or Python, and it works almost exactly the way the same code under Windows would. I've also got to admit that Microsoft got a leg up here with PowerShell, because rather than holding up to tradition from the 70s, they applied new modern thought to the problem and came up with something better. I think it's unfortunate that Linux has acquired a considerable amount of traditionalism, because that risks making it slow to adapt and improve.

every 4y ago
Unlike most religions, the Unix Philosophy actually produces positive and tangible results...
- legends2k 4y ago
  Care to substantiate your claim with examples other than the usual, now-old coreutils, binutils, etc.?
  - every 4y ago
    https://every.sdf.org/US_ASCII/Geekish/various/knuth-macilroy.txt https://every.sdf.org/US_ASCII/Geekish/various/knuth-macilro...

avgcorrection 4y ago

The Unix Philosophy as commonly invoked is rigged. You are apparently not allowed to implement the Philosophy on top of (as an application) Unix. Only by using the OS—which gives you the options of Unix, and… Windows?—are you practicing the philosophy. But hold on. What if you don’t have a lisp machine lying around? What if Unix, or Unix-likes, or asterisk-nix is all you’ve got? Well it seems you have to implement your own lisp platform and run it on those icky Unixen. Great, what could be more composable than an application which can be extended using Lisp, where key presses and functions are interchangeable? And now you get to communicate with your “small programs” on your Lisp platform. But then bam, you’re disqualified. Because now people have decided—for arbitrary reasons—that you have moved one level too far up.

a9h74j 4y ago
One gloss on comparative philosophy: *nix: Extendable command line (via C, etc) plus shell scripts Emacs: Extendable command line (via Lisp) plus keymaps
- Siira 4y ago
  Emacs can shell out just fine. Even the opposite is possible: You can ask a running emacs server to eval arbitrary code. I use both frequently.

jonjacky 4y ago

One of the original Unix creators, Doug McIlroy, credited with inventing pipes, wrote in [1]: "... I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. Emacs and vi raised that number to a high power ... ... Unix was born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities. But evolution, including the evolution of Unix, does not work that way. ..." The editors favored by the original Unix guys are ed, sam, and acme. 1. https://minnie.tuhs.org/pipermail/tuhs/2014-August/006506.html https://minnie.tuhs.org/pipermail/tuhs/2014-August/006506.ht...

taeric 4y ago
This is somewhat silly. First, the mystery chords for the terminal only grew. And... Is kind of the reason to use a different editor. Second, adding acme as a preferred editor throws the conceit by introducing the mouse to the chords. I fully grant that chords with the mouse probably add a lot, especially after training. I struggle to see how "small means" can lead you to any one editor over another, though.
return_to_monke 4y ago
But you can use these chords inside the editor's terminal (for example (n)vim's :term), so it's easier to scroll back, search stuff and copy-paste, for example
guenthert 4y ago
I can see that emacs (predating Unix) doesn't fit into the Unix philosophy (and I don't see a reason why it should -- it's first and foremost an editor, not a system tool), but "The editors favored by the original Unix guys are ed, sam, and acme." doesn't make any sense. vi was the VIsual interface to ed, so ed has all the mystery chords, just expects you to operate blindly.
- jonjacky 4y ago
  Some of the original Bell Labs Unix people have a very austere view of the Unix philosophy. In their view, it all started to go wrong -- Unix began to depart from the founding principles -- as early as 1978. In their view, Berkeley Unix does not follow their Unix philosophy -- they don't like network sockets, for example, whose design was mostly imported from some earlier non-Unix system (maybe Tenex?). Some of this attitude appears in Rob Pike's 'Good, Bad and Ugly' talk from 2001 [1]. He says the early Unix tools approach had, by then, already been replaced for most users by big do-everything programs: Emacs, Perl, browsers... 1. http://herpolhode.com/rob/ugly.pdf http://herpolhode.com/rob/ugly.pdf

somedudetbh 4y ago

It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" by people who presumably use Unix? Maybe it's a philosophy like "Don't do sins" is a philosophy of Christians? More of an aspiration than an actual practice? I can't really think of any Unix programs in common use that do one thing well. Inevitably, they grow to redundantly include features that other programs have. If anything can be said to be the actual lived Unix philosophy it's probably something like: 1) Try to make your programs communicate using text, where the 'record' is separated by a newline. 2) If you have a choice between making a program a little more friendly to use, or making it's text communication a little simpler to compose with, go with the second option. E.g. if there's nothing to output when a program runs don't output "Nothing to output", just output nothing. I don't think Emacs really fits with the unix philosophy, whether my version or the common version, at all. One of the main things I like about emacs is that it's like a vision of an alternate computing universe, where we assume that we're operating in a giant image that's meant to be programmed and customized all the time. What if most of your work was done in a LISP repl with a bunch of UI tweaks? It's like using a research project from a 70s or 80s "Future of Computing" lab that never actually shipped, except it did ship. It feels like it should have a lightpen attached. I don't even really think it's particularly practical to use emacs at this point, I just like this vibe and reminder that nothing about the way we use computers was inevitable so much that I stubbornly still use it.

__d 4y ago
The "Unix philosophy" is pretty debased in a modern Linux system. A BSD still has echoes of the original, but to get the pure experience, you should probably play with a Plan9 (maybe 9front), where the "one thing, well" bit is still taken seriously.
badsectoracula 4y ago
> It's so weird to me that "write programs that do one thing well" is constantly referred to as "The Unix Philosophy" [...] If anything can be said to be the actual lived Unix philosophy it's probably something like: 1) Try to make your programs communicate using text, where the 'record' is separated by a newline. [..etc..] The Unix Philosophy isn't just about writing programs that do one thing well (and FWIW it isn't really a philosophy or dogma, it is more of a guideline/goal), there are a bunch of things. The "write programs that do one thing well" is just one ways to think about it. The most common set of goals is: 1. Write programs that do one thing and do it well. 2. Write programs to work together. 3. Write programs to handle text streams, because that is a universal interface. But there is really more to it as can be seen in the Wikipedia page[0], like ESR's 19 rules and Mike Gancarz (who wrote the "The UNIX Philosophy" book from his experiences) 9 tenets (three of the most common being using flat text files for data, avoiding captive user interfaces as that makes composition harder and making programs act as filters). Really at the very core is the goal to make programs that can be glued together with other programs (often via scripts) to perform tasks and communicate in ways (pretty always via text) that humans can see so that they can stitch them together even if they know nothing about each other (for example even if two or more programs they use different formats for their input/output, since they use text, other common tools like grep, awk, etc can be used as filters/pipes directly or via scripts to connect them together). This is where the "do one thing" comes from: if your program acts as a filter and/or communicates just via text, there is no need to complicate your program by adding functionality that another program can provide since a user can simply glue the two together. For example if you have some program that returns the values of some sensors you don't need to add search or filtering functionality since one can use grep and awk for that. [0] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy

deleted 4y ago

[deleted]

bitwize 4y ago

Small, composable "Unix philosophy" programs need a substrate in order to work well, and that substrate can be heavyweight. The Unix kernel itself with its process and I/O model is one example (though Plan 9 may be considered an experiment in just how minimal that substrate can be while supporting the essential features of the model). The shell allows linking these programs together in a way that's relatively user-friendly, making the toolkit of composable programs accessible. Relatedly, the X server is a substrate that allows small modular programs to coordinate in different ways, composing to form a graphical desktop environment. I think Emacs on Unix is another such substrate. In a way, it's a sort of super-shell that can not only allow the user to compose Unix programs as with the shell, but to capture their input and output in buffers for further editing and processing. The ability to capture text, whether from files, programs, or network connections, edit it in a buffer, and script any operation with Lisp makes Emacs a tremendously powerful tool in its own right and an easily configurable coordinator for your other tools, with enough power to let you put a custom UI over them for smooth, flow-conducive access at your fingertips.

pjmlp 4y ago
Inferno was an even better experiment, the kernel and Limbo VM had a minimal attack surface, everything else was based on the same principles as Plan 9 and dynamically loadable modules written in Limbo.

cranium 4y ago

One could argue that Emacs is a lisp VM specialized for text edition, and in that sense does only one thing and does it well.

larsbrinkhoff 4y ago

"How Emacs fits inside of Unix philosophy" I see this time and again. Why is there a need to fit Emacs inside the Unix philosophy? I think it's perfectly fine if it doesn't.

TeMPOraL 4y ago
For the same reason certain religion known for door-to-door proselytism insists on being classified as Christianity: because it recruits from other Christian groups. Similarly, Emacs recruits users mainly from software devs and Linux users, many of whom have almost religious belief in Unix philosophy.

xenodium 4y ago

While I'm no elisp expert, I know enough to glue all sorts of utils. It enables scratching my own itches, often resulting in accessible workflows that do exactly what I mean. Some recent examples: Hey Emacs, where did I take that photo? - https://xenodium.com/hey-emacs-where-did-i-take-that-photo https://xenodium.com/hey-emacs-where-did-i-take-that-photo Emacs: Open with macOS app - https://xenodium.com/emacs-open-with-macos-app https://xenodium.com/emacs-open-with-macos-app Emacs: Reveal in macOS Finder (DWIM style) - https://xenodium.com/emacs-reveal-in-finder-dwim-style https://xenodium.com/emacs-reveal-in-finder-dwim-style Seamless command-line utils - https://xenodium.com/seamless-command-line-utils https://xenodium.com/seamless-command-line-utils

James_K 4y ago

The UNIX philosophy is redundant. The only unique part of it is to use text for everything, which isn't a very good piece of advice. It only exists to cover for the mistakes of UNIX. The bulk of it is saying that you should apply the same design principals you would on the inside of a program to the external interface of it. The irony here is that people only treat these situations differently because UNIX forces programs to interact through limited means (a single function which accepts an array of strings as its arguments). If UNIX allowed programs to represent themselves as modules of functions which act on datastructures richer than a string, it would be obvious to everyone that they should apply good programming principals to these modules. Case in point: Emacs. Its programs are modular, so it needs no grand philosophy telling programmers to apply the well known practices of good design. The `find' utility is the exact sort of thing that the UNIX philosophy warns against. It contains huge amounts of duplicate functionality; I believe the version installed on my system takes more than a hundred flags. No such functions exist in Emacs, because it would never occur to someone that they should write a function with over a hundred keyword arguments to do something as basic as file handling. The advice in the UNIX philosophy exists only to combat the issues that UNIX creates, which is why I am so confused by the fact that so many people are reverent to it. They act as though UNIX invented simplicity or good design, as though the application thereof is something special rather than what should be the default for any competent programmer. I can only speculate why this happens. My personal view is that UNIX has locked us into systems that don't follow its own philosophy. People come to view this failure as the default, so any instance of good design is remarkable.