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

One gloss on comparative philosophy:

*nix: Extendable command line (via C, etc) plus shell scripts

Emacs: Extendable command line (via Lisp) plus keymaps

Great example! Yes, the way org-mode and the various email systems play nicely together is sheer beauty. Nothing like it.

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.

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.

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

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.

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.

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

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.

That paper is about 'emacs lisp', not emacs itself, which came out of systems running on various PDPs.

I love my Stockholm syndrome on .NET, Visual Studio, Delphi, C++ Builder, PowerShell, DirectX.

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.

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.

> 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

Eric Raymond covered your "actual lived Unix philosophy" points in The Art of Unix Programming: https://www.catb.org/esr/writings/taoup/

It's worth a read, but do bear in mind that the whole Unix mindset is an evolutionary dead end.

I mean the sad fact is that we're slowly learning that Unix with all its baggage is like an internal combustion engine: it seemed like a good idea at the time, so we adopted it, and now it's ubiquitous and it's a race to move on to something else before the bill for all the damage it's caused civilization comes due. People favor comprehensive, feature-rich programs over small composable ones. The Unix process model and fork(2) in particular break down utterly in the presence of threads. It took fucking forever in tech-industry time to come up with a single solution for dynamic linking, something Windows and Amiga OS solved in the fucking 80s. Linux is only just now getting an async I/O solution that begins to approach the robustness and comprehensive of what VMS had in the 80s and Windows NT had in the early 90s; before that, it went with the Unix assumption of "disk I/O takes zero time to execute, and you can poll for everything else!" You want to know what else Windows had in the early 90s that Unix, and especially Linux, only caught up with in slipshod fashion later? ACLs. One reason why Windows got an EAL4 certification under the Common Criteria well before Linux.

Postel's law was wrong (you want strict protocol conformance to avoid surprising behavior), ASCII text protocols were a mistake (parsing and unparsing them just converts electricity into waste heat), piping together unstructured blobs of text is NOT robust and programs should communicate via objects with checkable types... Just, on and on, mistake after mistake.

And C. Just... C. If null pointers were the billion dollar mistake, how many trillions' worth of damage were done by the totality of all C's foibles, pitfalls, and undefined behaviors? Honestly if we do nothing else, we should halt ALL greenfield development in C. It's unsafe at any speed.

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.

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.

Unlike most religions, the Unix Philosophy actually produces positive and tangible results...

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.

I moved from VSCode to Emacs with the help of Doom Emacs. You can check it out online. It’s a distribution and configuration management solution.

Generally people like to recommend writing your config from scratch but that didn’t work for me.

It comes with pretty much all you requested out of the box.

One thing I liked more than with the default Emacs setup is that I could “activate” support for a Language just by un-commenting a line in the well organized config.

Picking eMacs up as a replacement for VSCode while having to get stuff done is risky. I would venture to say that it’s not realistic as far as your conceptualization. I say this because you venture to ask if the setup process is similar. The answer is a resounding no. VSCode is incredibly easy to “get productive” and eMacs is on the other end of the spectrum.

That being said, if you can work some time into your schedule to learn eMacs, your goal can be realized. (Also, it’s totally worth it.) I was a VSCode user and made some time to learn eMacs exclusively for org mode (possibly eMacs’s coolest feature). Once I was comfortable, I just played around with a dev environment in eMacs (for fun) and loved it so much that I left VSCode.

Don't forget to check out the MELPA (melpa.org) repository, which has a staggering array of packages for Emacs. If people do something on computers, chances are someone does it in Emacs and there's a package on MELPA to support it.

Also, the road to Emacs proficiency will be a journey, and you'll want to think about Emacs as something you'll gradually tinker with and tweak to get to a set up and understanding that is satisfying. It's not shiny nor whiz-bang by any means, but path through the learning curve can be extremely rewarding.

Treat it like a game for a while. Don't even try to be productive, just play with it and see how the pieces fit together.

I found the ebook Mastering Emacs, and the accompanying blog to be extremely useful, even after going through both Spacemacs and Doom Emacs. I may go back to a modal workflow in the future, but for now I'm embracing Emacs' built-in ways of doing things, with a few exceptions.

http://www.masteringemacs.org

You may balk at the $50 pricing, but it gives the most complete picture of how Emacs works than anything else.

The way I did it was by not using it for my entire workflow right away. The trojan horse for me was org-mode. Doom Emacs got me started in what felt to be a more modern UX, and I used org-mode not for coding outright, but for note taking and personal project management. After a while, I started to use org-mode's built in ability to run code via org-babel to experiment with ideas in code. Eventually I was comfortable enough that I just started using it to code some times instead of VS Code, because I was already there. I still dual-use VS Code and Emacs because VS Code is still better at some things (working with files on remote server is still kinda slow via TRAMP some times) but I'm about 85% in Emacs now, since I like it better for text traversal, org-mode has become more integrated into my workflow with things like tangle, and I like magit better than VS Code's built-in git interface.

I second the suggestion to start off with org mode. You get a low stakes note taking utility to use while getting comfortable with emacs. From there spread out to learn other features at your own pace.

Not exactly what you’re asking for, but check some articles and videos about org-mode. There’s a chance you’ll get hooked on it and the following learning will be much easier because damn, it’s worth all the pain. Well, at least that was my case.

> 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?

Only use the new system on Friday afternoons or whenever your typical slow periods or lulls happen until you get used to it.

If you plan to customize your workflow and extend your system I recommend:

https://github.com/SystemCrafters/crafted-emacs

If you want more out of the box, but harder to debug and extend I'd recommend:

https://github.com/doomemacs/doomemacs (you can use vanilla or vim keybindings)

In either case I'll echo the user recommending Mastering emacs.

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.