Back to the schedule
Previous: Emacs manuals translation and OmegaT
Next: Emacs and Montessori Philosophy

GNU's Not UNIX: Why Emacs Demonstrates The UNIX Philosophy Isn't Always The Only Answer

Daniel Rose

Q&A: live
Status: Finished
Duration: 6:41

This talk will also be streamed at an alternate time for APAC hours: https://libreau.org/upcoming.html#emacsconf21

If you have questions and the speaker has not indicated public contact information on this page, please feel free to e-mail us at emacsconf-submit@gnu.org and we'll forward your question to the speaker.

Description

The talk targets users who are curious about computational philosophies, or those who might not know how to best utilise Emacs conceptually. The talk will cover what the UNIX philosophy is, the GNU Free Software principles, a typical (Neo)Vi(m) user's approach, and then how one might accomplish this in Emacs combining the aformentioned ideals. The listeners will learn how they can approach Emacs ideologically, and how blocking themselves into one philosophy or the other will limit their efficiency. Although you may be a veteran GNU/Linux and Emacs user, understanding how to use both philosophies together will still allow you to be more performant than without.

Discussion

IRC nick: thecatster

Feedback:

  • I really appreciate this talk's perspective! I'm very invested in living inside, Emacs, but this is also a great perspective!
  • yes, nice perspective. Saying that I am struggeling with that is overstating it, but sometimes it does make me think. thank you Daniel!
  • Nice talk, I feel like some Emacs purists could complain but let's be honest, this is a reasonable take on actually getting stuff done

Outline

  • How can one limit their usage of CLI tools while still maintaining the ideals of both.
  • How using CLI tools can still perfectly flow into Emacs.
  • How having all programs in Emacs and unified keybindings is akin to a terminal user.
  • Why thinking about computational philosophies might itself be an impediment.

Transcript

[00:00:00.080] Hello! My name is Daniel or Daniil Rose. I use Emacs in my everyday life, from programming in C or Rust for work, to writing reports for classes. I'd like to start by adding an overarching theme to this talk. If there's only one thing that you remember from today, I'd like you to walk away with the understanding that the philosophies or ideologies are just that. By trying to box yourself in with a concept you might be blind to other methods. We live in an ever-changing world, and I hope that you can appreciate being flexible and adaptable.

[00:00:31.599] UNIX philosophy? As a quick intro for those who don't know, the UNIX philosophy was written by Doug McIlroy. It's wordy, so there is a great summarization by Peter H. Salus: Write programs that do one thing and do it well. Write programs to work together, and write programs to handle text streams, because they are the universal interface.

[00:00:57.600] So enter Emacs. Emacs doesn't quite adhere to those principles. "Do one thing and do it well" surely doesn't apply, since Emacs does /a lot/ of things and does the majority of those things well. It might apply if you consider Emacs purely as a Lisp environment, however. "Write programs to work together?" Arguably the thing Emacs is best out of the three, proven especially by all the various packages that work with external programs, LSP, and whatever else. "Handle text streams?" Well, that one depends.

[00:01:25.439] So, Emacs versus the original ideas. The summarizations are good, but they aren't truly what was said. If we look back at the originals, we'll see that Emacs strongly adheres to the second rule: Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. The concept of LISP, self documentation of Emacs, and the "REPL" style all make it a shining example of this rule.

[00:01:50.799] But why compare to UNIX? Truly, why compare to the UNIX philosophy? Although the "rules" set down are good ones for most programs, Emacs isn't most programs. The rules and summarizations even were written decades ago, before we had REST APIs, JSON, or any other modern interface. If the world adapts, why too can't we adapt the past? This concept of breaking the rules and forging its own path has allowed Emacs to continue and be reworked for modern eras.

[00:02:17.440] Emacs /does/ work with the UNIX philosophy. By looking at both of these ideologies, why must they be mutually exclusive? Emacs does work with text: Magit is a wrapper for the git CLI Dired is a wrapper for ls, Consult grep for grep, and so on. Why rewrite poorly tools, when we can use the existing powerful ones? Well, that in itself is part of the UNIX philosophy. It seems that most strongly the UNIX philosophy applies to the command line. If we look at most graphical applications, these notions fall apart. But that isn't true for Emacs. It is a graphical application (at least for me) but it does use many other tools. Some have proposed that Emacs should be looked at alongside UNIX, as its own OS. It has windowing capabilities handles its own formats, and so on, but I disagree with this concept.

[00:02:59.650] Philosophies don't really matter in computing. It's true, they don't. As people, we like to group things. We like to have our set ways to describe them, but that doesn't always work. By sticking with a common concept in the Emacs community, do everything in Emacs, is it truly benefitting me and you?

[00:03:15.050] Android Studio. Here's an example. I work most often in Emacs. But I also have courses in Android and iOS development. I can absolutely install ~android-mode~ and ~kotlin-mode~, and use ~adb~ in Emacs, but at that point, I am creating more work than it's worth. When unmaintained, things tend to fall apart, and many features of ~android-mode~ no longer work for me. So I have two main options: fix the existing mode or write my own, or use the assumed tools for the job, like Android Studio and/or IntelliJ. Looking at Android Studio: I have plenty of plugins for colour themes, just like Emacs. I have Emacs keybindings built in, and other quality-of-life features. According to the UNIX philosophy, in a round-about way, I should be using one tool that does its job well. While not minimal, Android Studio accomplishes this job. Does that mean that I shouldn't use Emacs at all? Of course not! And while it may seem obvious, I feel we in this group often get caught up finding solutions in the one particular way we want it. This is where being adaptable comes in again. I need to learn how to mold my tools to my workflow, but also mold my workflow to the tools available.

[00:04:14.383] Window Managers. Another example of this is window managers. Although I've probably dabbled in window managers or desktop environments as much as the next person, I have usually stuck with DWM. But DWM doesn't follow any of the Emacs concepts: it has different keybindings-- you can sort of do Emacs ones, no REPL (it's a C program after all). But I can still mold it to my workflow. If I run Emacs as a daemon and a client, what difference is it? My WM is essentially a wrapper for Emacs and my other vital programs. I don't need to make Emacs my WM, and bring along all the other issues.

[00:04:42.900] Browsers are a similar conversation. Initially, I understand the value of having my browser in Emacs, but why? If a tool exists that works well, ignoring the UNIX philosophy for a moment, why should I take the effort to rewrite it? Now, don't misinterpret what I'm saying. If you have a better way to do something: you can make it faster, easier to use, that I understand. But if I have, say, Nyxt or Firefox? Why would I take the effort to try and rewrite that into Emacs? Instead, this is a scenario where using a different tool alongside Emacs might be better. There's a talk later on in the conference about that from someone else.

[00:05:09.300] Vim. Even vim, jokingly, is the enemy of our community, but it's a good tool. Sometimes I just don't want to run Emacs as a daemon with evil-mode and I just want to quickly do something. And most people come from a power user terminal background, or at least I would assume s,. and those I have spoken with. If I need to quickly edit something, it might benefit me to just run a quick vim ./file in the terminal. I often have terminals open anyway due to the graphic acceleration from things like Alacritty.

[00:05:34.639] Speaking of terminals, this is the main tool I don't use in Emacs. While vterm might be nice, I often want to use a TUI tool. I most often write programs in C or Rust due to those being my main languages that I use professionally. If I can write a faster C or Rust program in half the time it'll take for me to write a slower Elisp one, I might prefer to do just that. Especially in the case of a TUI program, Alacritty helps me develop them faster but also run them. So if you've been using systemd or running commands in the terminal for years, it might take more effort to learn the way to do it in an Emacs frontend than in the terminal. And remember, most shells come with Emacs key bindings by default and macOS, for example, can use Emacs keybindings in most places including browsers.

[00:06:12.233] Do what helps you most, not what a philosophy or group tells you to do. I hope this illustrated some ways that Emacs is a tool in your belt, but not the belt itself. Do what works best for you, as being the most efficient doesn't always grant the best results. If you're used to doing something one way, consider still doing it that way while learning new skills and being adaptable. And after all, this is an Emacs conference so maybe consider learning a tool for both Emacs and the terminal, and then you might be just a little bit more flexible in the future. Thank you for listening to my talk today.

Back to the schedule
Previous: Emacs manuals translation and OmegaT
Next: Emacs and Montessori Philosophy