Forem: Ryan Faulhaber

Cool Emacs Things: Evil

Ryan Faulhaber — Sun, 19 Sep 2021 16:00:11 +0000

I like Vim a lot. I've been a Vim user for almost my entire professional career at this point. I learned Vim because the idea of editing text without touching the mouse appealed to me (also because I was tired of not knowing how to use Vim in environments without graphical editors. Pro tip, if you're in this situation and don't want to learn Vim: use Nano). Now I can't edit text without it. For a while I used Vim proper, and then I used other editors with their Vim emulators.

Once I learned Vim, Vim proper was my editor for a while. I learned all about plugins and had a small configuration file (now a Nix configuration). After a while though I found Vim itself cumbersome, and realized every other editor had a Vim plugin. So for a while I used IdeaVim, Atom's Vim plugin, and then finally VSCode's Vim plugin.

In my own experience, I've noticed that even Vim users underestimate Vim. Many Vim users I've known only learn the motions and stop there. Vim has some powerful functionality that a good number of people aren't aware of or don't use. Many Vim users seem satisfied to know the motions and leave it at that. And that's fine! I was that way for a very long time. But sometimes, I found myself wanting more advanced functionality that plugins couldn't offer.

Finally, I started using Emacs through Spacemacs, and then changed to Doom Emacs. Each configuration comes with Vim emulation through a package called Evil, the very cleverly named Extensible VI Layer for Emacs.

As a baseline, Evil does, at the very least, everything every other Vim plugin does. If you're familiar with Vim keybindings, motions, macros, marks, and the like, Evil supports those. But I wouldn't be writing about Evil if that was all it did! In fact I think it's safe to say that Evil is the most complete Vim emulator out there outside of Vim itself.

To me, one of the most noteworthy differences from other Vim emulators is that Evil has extensive Ex support. Ex commands are not very well supported in the other Vim plugins I've tried. Evil supports many of the basic Ex commands, such as :r, :w, :!, and so on, but also :normal, :global, and ranges. Evil doesn't implement every Ex command, though, since a good deal of Ex commands would be redundant in Emacs, such as ones like :set. It's also easy to define your own Ex commands. Evil provides evil-ex-define-cmd, allowing you to implement your own Ex commands. Doom provides some useful extras on top of Evil.

But the biggest difference between Evil and other Vim emulators is that Evil is an Emacs extension. When you configure Evil, you write Emacs Lisp, the same as any other configuration for Emacs. So Evil does not provide commands like :nnoremap. This is not so with, for example, IdeaVim or VSCode's Vim plugins. That said, you could think of Emacs Lisp as a stand in for Vimscript. This means that any Evil customization will use all Emacs's ability for customization and text-editing. The things Evil does not implement, as far as I can tell, would be redundant in Emacs.

This, to me, is the biggest advantage of Evil: it's as extensible as Emacs itself is. While Evil may not offer complete feature parity with Vim (I can't imagine having or even wanting a Vimscript interpreter, for example), it contains all the important parts, and a lot more than any other emulator I've used.

Were it not for Evil, I would not have continued using Emacs. For me, it's a crucial package.

Cool Emacs Things: Dired

Ryan Faulhaber — Fri, 28 May 2021 19:31:12 +0000

Today we continue my ongoing series on Emacs with a feature of Emacs that feels genuinely magical: Dired.

One of the first things I did when I became a Linux user was to learn how to use the terminal. The terminal is an indispensable tool in the Unix world broadly because of its versatility. I got to a point where I used the terminal so heavily that eventually on Linux I stopped installing file explorers, and on macOS I had entire directories that never had those annoying .DS_Store files. Personally, managing files in the terminal is often much simpler and more direct than a graphical file explorer.

Navigating your file system without a graphical file explorer requires you to know two standard Unix programs: cd (change directory) and ls (list directory contents). ls in particular can print out very detailed information about the files in your system:

# navigate to a project directory
cd ~/Projects/dial
# print contents
ls -lh

total	32K
drwxr-xr-x	3	ryan	users	4.0K	May	1	15:48	bin
-rw-r--r--	1	ryan	users	7.2K	May	2	12:39	Cargo.lock
-rw-r--r--	1	ryan	users	78	May	1	15:53	Cargo.toml
drwxr-xr-x	3	ryan	users	4.0K	May	1	15:49	dial-core
drwxr-xr-x	3	ryan	users	4.0K	May	1	15:53	parse
-rw-r--r--	1	ryan	users	186	May	1	15:36	README.org
drwxr-xr-x	3	ryan	users	4.0K	May	1	15:49	target

From left-to-right, these columns represent: file permissions (modifiable by chmod), links to this file, file owner (modifiable by chown), group owner (modifiable by chgrp), file size, last modified timestamp, and file name.

Dired defies explanation for those who haven't used it, and while writing this I struggled with how to explain it exactly. I'm tempted to describe it as "interactive ls".

Imagine if, when you typed ls and got a list of files, you could click on those names. If the name is a directory, your terminal would automatically cd to that directory and invoke ls again. If that name is a file, your terminal opens that file in your favorite text editor. If your favorite text editor is Emacs, I have good news for you: this is what Dired is.

But Dired does a little more than just navigation: Dired is a file explorer in its own right. From Dired you can move, copy, rename, and delete files, make links, run rsync (with an extra package), diff files, and more.

But that's not all! Dired has a sibling called wdired-mode, or "writable Dired." wdired lets you edit a Dired buffer, thereby allowing you to rename files with all the editing powers of Emacs. So, for example, replacing all of your .js to .ts files is just a matter of finding and replacing js with ts. wdired will also let you change file permissions, so you could change rw-r--r-- to, say, rw-rw-rw- by simply changing the text without having to break out chmod.

This is why I navigate my file explorer in Emacs rather than my terminal now.

Quest for a Better Scripting Language

Ryan Faulhaber — Tue, 27 Apr 2021 21:33:39 +0000

I’ve been a Linux user for quite a few years now, and writing shell scripts is a pretty common thing for me. I have written many little scripts to do repetitive tasks in various languages. In this post I want to think out loud about what makes a worthwhile scripting language.

Also please note that these are purely my opinions based on subjective experience, I’m not really interested in making any objective claims in this post. Your mileage may very with any of these languages.

The Goal

Before we set out on our tour of languages, I want to make clear what I’m looking for: I’m not looking for the perfect programming language, I’m looking for a language that makes automating tasks easier. Such tasks may include anything like renaming every file in a directory, parsing Git CLI output, automating AWS tasks, and so on. These are things I do on a daily basis that are repetitive and could be automated, and I’m looking for a tool that makes doing these things easiest. These tasks also tend to be ad hoc as well and not something that could be solved by simply using GitKraken or something.

So in my experience, this is the kind of thing where you’d reach for a language like Bash over, say, Java. Although you could write a full-blown tool to solve some problem in Java, more often than not it’s a little overkill (I don’t fault anyone who does this! To each their own, but I’m looking for something more lightweight).

What I want is something that:

Writes to stdout and reads stdin easily
Runs commands trivially
Is easy to write on the fly, such as in a REPL
Is portable and doesn’t expect much from its user (i.e. should either use software that one can reasonably expect to be installed on a system or requires minimal installation such as running brew install or similar)

With that, let’s review the languages I’ve used.

Bash

Bash is a natural candidate: it comes on every Unix-like system, it’s trivial to run commands with, it uses stdin and stdout trivially, and it has a long history behind it, with lots of resources online for how to accomplish tasks. I have written many Bash scripts myself and for many years used it as my shell (I now use Zsh though).

Bash would be much less useful without many of the programs that also come standard on a Unix system though, such as sed and tail. Programs like these let you write very modular and robust commands, such as:

git tag | tail -n 1 | xargs -I {} jq -n --arg tag {} '{tag: $tag}'

These programs don’t have to know anything about the other, but through the magic of stdin and stdout, they can communicate with one another.

The biggest downside to Bash though is that it’s a weird language, and that its simplicity sometimes makes it obtuse. Bash has functions for example, but they can only return status codes and not values. Bash is also difficult to test: you can’t just do a dry-run of your script without changing your environment somehow (sure you could run your script in a Docker container or something, but that’s not exactly trivial). I almost consider writing more than about 10 lines of Bash to be a red flag.

To summarize, Bash is good at what it does and almost gets me where I need, but it’s idiosyncrasies cause easy mistakes, and surely we can do better.

Python

It’s hard not to mention Python, one of the most popularly used languages. I’ve never been paid to write Python but I have written quite a bit of it (and overall I have very mixed feelings about Python as a language). When I was in college, and for a bit of time after, I wrote lots of Python to do tasks around my computer. Python seems to be a modern Perl in that regard.

Python isn’t a shell language. You can’t just open it up and type ls and expect it to do something. But otherwise, coming with all the bells and whistles of a full-blown programming language, it’s easy to write. And to its credit, Python is a very expressive language.

For me, Python is what I’d reach for when I want to do something more complicated that would be a pain to do in Bash.

Ruby

With the decline in popularity of Rails it seems that Ruby isn’t as popular as it once was. That said, when it was more popular, I wrote a ton of Ruby scripts to do various tasks.

Ruby to me has always been just “Python but better.” Python seems to suffer from years of incoherent design while Ruby does less so. Ruby also just has a lot of interesting language features.

Like Python, Ruby is not a shell language. That said, Ruby is at least as good as Python and comes with a lot of neat little utilities to make writing code easier.

I have a soft spot for Ruby but don’t write much of it anymore.

JavaScript

JavaScript is not a perfect language but despite that fact I will die on a hill defending it. Although I believe that JavaScript is often unfairly maligned and is a better language than most people think, this is one regard where I cannot stand by it.

Writing any JavaScript code that interacts with the file system is a chore at best, though this is perhaps the fault of Node than it is JavaScript in particular. JavaScript is, while not the most verbose language out there, still requires a lot of code to do simple things around the system. I personally find JavaScript unsuitable for such tasks. It’s better for writing applications.¹

Emacs Lisp

This is something of a wild card in this list.

I use Emacs, and once you really get into the Emacs world, you tend to want to just do everything in Emacs, and Emacs is more than happy to let you do that. You can customize Emacs with Emacs Lisp, a cousin of Common Lisp.

I don’t think that Lisps are necessarily hard to write, but they can be hard to read if you’re not used to mentally parsing a million parentheses. Emacs Lisp isn’t the best Lisp in the world but it does make customizing Emacs pretty easy.

Emacs Lisp is pretty good at interacting with files and running commands.

;; emacs lisp has built-in functions that can do similar things,
;; but for the sake of an example...
(let ((output (shell-command-to-string "ls *.org")))
  (length (split-string output "\n")))

Emacs also came to mind because Emacs comes with a built-in Emacs Lisp shell, called Eshell. Eshell is like any other shell, except that instead of, say, using the Bash language, it uses Emacs Lisp. Eshell is an okay shell and is good for doing things here and there, but the idea of a Lisp shell is pretty interesting to me. I’ve never seen any other Lisp shells, however.

Although personally I feel that Emacs Lisp is an acceptable solution for personal use, it does depend on Emacs. Emacs runs on all my systems so for my own personal use it’s also acceptable in that regard. You may be out of luck though if your coworker, who does not use Emacs, needs a solution to a problem you’ve already solved with Emacs Lisp.

Conclusions

By writing this post I feel like I’ve hit a limit with the tools that I have. I feel like in the above languages I’ve only found partial solutions. The problem with existing shells is that the languages tend to be obtuse and fall apart for more complicated tasks, and the programming languages have the inverse problem. I feel that there must be a solution out there that resolves this apparent contradiction between shell scripting and full-blown programming languages. I can’t help but feel that maybe it’s time for a new tool to this end.

What would a new language look like? Much like the goals above, I think it would:

Be interactive, e.g. typing ls and hitting enter runs ls
Support commands as first class (see Bash)
Have enough language support that it would be relatively easy to write longer scripts
Use modern language conventions to make writing longer scripts easier while also not bogging down the expressiveness of the language
Support redirection and piping as syntax (perhaps Bash’s biggest strength)

Honorable mentions

Here is a brief discussion on possible candidates that I don’t know enough about but look interesting.

Perl

I don’t know any Perl and there’s a chance I probably never well, I can’t help but feel that I missed the boat on this one. Recent developments in the Perl world make it seem interesting, and it seems that the Perl community has done a lot of work to improve the language in recent years.

AWK

It’s a shame I don’t know AWK and I’ve been meaning to fix this for years. The very little AWK I know is interesting, and my impression of AWK is that it seems like a way to write ad hoc programs in the middle of a Bash script. Maybe you want something sed can do but it’s just kind of a pain to write in sed? AWK can probably do it.

Lua

I just started writing Lua as I recently discovered Hammerspoon. Lua reminds me a lot of JavaScript and seems like it’d be a good Python / Ruby replacement. I don’t know much about it otherwise.

Tcl

I stumbled across Tcl recently and I’m pretty intrigued by it. It seems like a deliberate attempt to improve a language like Bash, and it has a shell called Tclsh. Tcl has more “proper” language features that I think would eliminate a number of pain points with Bash, but I’m not sure how it would fare for large, complicated tasks. It might be worth investigating.

Koi

Koi is a little language I stumbled across on GitHub. It seems like it hits the sweet spot of being both interactive and easy to write. I haven’t had much of a chance to mess around with it but it seems really cool and is exactly what I’d want out of a language like this.

Footnotes

¹ To be clear, I should mention that I’m not just singling out JavaScript in this regard. Other languages such as Java, C#, Go, Rust, etc. likely fit this bill to for similar reasons, but I mention JavaScript in particular only because I’ve tried to write scripts with it.

Cool Emacs Things: Magit

Ryan Faulhaber — Sat, 21 Nov 2020 21:13:34 +0000

This is part of an ongoing series where I talk about the little things that make Emacs a nice editor. Today's entry: Magit, a Git interface for Emacs.

I'm not much of a Git client person myself. I don't use or particularly like Sourcetree or GitKraken. VS Code and JetBrains IDEs have some nice features, especially when it comes to merging and rebasing, but they're still not quite like Magit.

Until I used Magit I interacted with Git through the command line, because Git in the command line supported all of Git's features. I didn't have to worry about whether GitKraken supported viewing the reflog or file history, I could run git reflog and git log file and not have to worry about it.

Magit on its surface isn't all that different from the VS Code Git integration: you can pull and push code, see diffs, read the Git log, and so on. But what makes Magit special is that its integration with Emacs makes it very ergonomic to use.

I'll illustrate with an example of committing some changes. After making some changes, I'll go to the Magit buffer and see this:

This is roughly the same as running git status: I see a list of files I've modified and whether they're staged. If I move my cursor down and hit Enter on the file name, it'll take me to the file in question.

If I hover over the filename and type d I'm presented with some choices regarding seeing the differences. After hitting d again I'm presented with a window that shows the diffs:

I can stage individual files by typing s over the filenames, or staging groups of files by highlighting several and hitting s.

Finally, if I want to make a commit, I type c from the Magit buffer and presented with a number of useful options, not unfamiliar to us Git command-line users:

Each one of these arguments are actual Git arguments that will be applied to your Git commit.

Finally, the commit window.

Magit provides a normal text buffer for writing a commit message (with all of the conveniences of Emacs of course). The first line is only supposed to be 50 characters long so Magit will mark any extra text in red. Below is the diff for the commit you're making.

Once I'm ready to commit, I type C-c C-c.

Magit supports not only what appears to be most Git functionality, but you can modify this behavior using actual options that Git gives you. In terms of the interface, Magit makes it very easy to understand what Git commands it'll be running, and in turn passes along greater control to you. If, for example, I wanted to force push this code for some reason, I'd run M-x magit-push (or simply p from a Magit buffer), I'll see this:

This looks similar to the commit window we saw earlier.

After typing -F I've turned on the --force flag, and Magit will run git push --force instead.

I like Magit because, unlike Sourcetree or even the terminal you don't have to leave the editor to do Git things, and unlike VS Code or IntelliJ, I can perform all these Git actions without ever having to touch the mouse.

Magit can do a lot more than this, of course, but even if this was all it could do it would probably still be my favorite Git client. To me it's yet another reason to use Emacs.

Critique of the Magic of Modern IDEs

Ryan Faulhaber — Sun, 15 Nov 2020 18:26:11 +0000

The StackOverflow blog recently posted this article asking why so many people continue to use Vim and Emacs when modern editors like Atom exist. This is a question I have personally addressed before with regards to Emacs, but I want to address this post specifically because I think it gets at a commonly held misunderstanding about these editors.

The basic point of the post explores why people would want to use an antiquated editor like Vim or Emacs, and that those who continue to use either are missing out on the so-called magic of a newer IDE.

I think that this post doesn't understand why someone would want to use Vim or Emacs in the first place, and is happy to throw them into the dustbin of history simply because they're old. In fact Vim and Emacs still have a lot to offer, and each are able to offer things that newer editors simply aren't interested in providing.

What is an IDE?

As anyone will tell you, an IDE is an integrated development environment. This is a catchall term for a special kind of text editor that provides special functionality for writing code. What separates Notepad on Windows from, say, IntelliJ IDEA is that the latter has features that enable you to compile and run programs, code completion, version control integration, and a whole host of other things.

Increasingly the line between IDE and text editor is blurring, however. Something like VS Code or Atom can be considered either depending on who you ask. Typically, I would consider Atom a text editor while I'd consider IntelliJ IDEA an IDE, because the latter is specifically suited for providing a Java development environment (and about a dozen other languages as well): it comes with Java-specific code completion, compiling and running commands, and so forth, while Atom inherently does not, though it can be made to do so. Visual Studio can do the same for C#. Vim, Atom, VS Code, and Emacs inherently do not.

The So-Called Magic of IDEs

In my first software class in college we wrote Java using Eclipse. The course mandated that you use Eclipse to compile your code, and the first class involved setting up our environment in such a way that we wouldn't have to worry about configuring our IDE for the rest of the course. This was the first time I wrote Java and for a long time didn't know that you could run Java code any other way.

I was in for a shock when I took my first C class a semester later. The professor forbade us from using an IDE, instead we had to use gcc with the -ansi flag. Per the requirements of the course I wrote all my code in gedit and compiled it manually in the terminal. Compiling code in this manner was frustrating: I didn't notice issues with my code until I ran gcc, and I wouldn't know if I had resolved my issue until I reran the command. Doing this with an IDE wouldn't be so frustrating, I thought!

This experience taught me three things, and it's a lesson I feel everyone who writes code sooner or later learns:

You don't need an IDE to compile and run code. It seems obvious in retrospect but learning how to code in this way presents how code works in a mystified way.
Your tools are only as good as you utilize them. While gedit didn't provide me with much useful feedback on my C code as I wrote it, gcc sure did. Learning to listen to the warnings saved me a bit of grief as I went through the course. Learning other tools like make also made my life easier at the time. This holds true for any editor as well: IntelliJ provides an astronomical amount of features, but if all I do is use this huge editor to just compile and run Java, what difference does it make if I wrote my code in gedit and compile my code from the command line?
Usually you don't need a specific editor to write code. Code written in Vim is the same as code written in Visual Studio, but these are tools meant to assist you. Code running on a server somewhere doesn't care whether or not it was written in Emacs or Sublime.

All of this is to say that an IDE is a tool of mystification: it deliberately makes writing code easier, and does so by automating the more tedious aspects of the process. As a software developer I feel that it's important to know how to do these things yourself, as doing so will result in a deeper understanding of the code you write.

The Cold Vim/Emacs War

I want to address the so-called war between Vim and Emacs, and I want to start by asking: what war is there?

If you had never heard of Vim or Emacs before this article you would think that there are deeply embedded communities who spend all day in flame wars over which editor they prefer, and their refusal to move on was holding back the whole of software engineering.

But where is this? The article points to a Medium article that talks about how a developer turned Atom into Vim, and says that this attitude is retrograde: the author is so entrenched in the past that they used Atom's customizability to turn it into something that more closely resembles Vim.

I have been using Vim for four years and Emacs for almost one (and in fact I use Vim keybindings within Emacs!), and I've never seen any serious hostility between Vim and Emacs users. The original antagonism between the two editors came from Richard Stallman's objection to Vi being closed source. This is no longer relevant, however, as both Vim and Emacs are both free and open source software. I think there are people who prefer to use one over the other, in the same way some people would prefer chocolate or vanilla ice cream, but I think any serious animosity between Vim and Emacs users dried up decades ago.

Why use Vim or Emacs?

It's at this point I wonder if either of the authors of this piece have ever used Vim or Emacs! They certainly don't understand what the appeal of either would be, or why you'd want to import features from Vim into Atom, and if there's a desire to import features from Vim or Emacs into a modern editor like Atom, then modern editors clearly lack something.

To sum up what each editor offers, Vim offers ergonomics and Emacs offers customizability, and each of these are things you truly cannot appreciate until you have used either.

Vim's keybindings are meant to maximize keyboard use and cut down on repetitive editing actions. If you want to change what's between a set of parentheses, Vim lets you do this by typing ci(. Rather than reach for the mouse and highlight the contents, Vim saves you from having to move your hands. It takes some getting used to but is well worth the effort to learn.

Emacs offers something more subtle and profound, I think: an editor that can do exactly what you want it to do, and as a software developer, this is an invaluable feature to me. As "hackable" as Atom is, Emacs takes it to a greater extreme, allowing you to change even the most fundamental behavior of your editor. Frequently I write small functions in Emacs Lisp to tweak the behavior of the editor. I'm an avid Org mode user, and I have a small handful of functions to automate otherwise tedious actions, such as converting numbers to links to tickets in JIRA.

To say that Vim and Emacs themselves or their users somehow hold back modern editors, or that newer developers shouldn't bother with these tools is absurd. I have only been a professional developer for about four years and I've spent three of them using either Vim or Vim plugins. I feel that I'm a much more productive developer now that I know Vim, and using Vim and Emacs in turn has taught me new ways to utilize the tools I use on a day-to-day basis. This isn't to say you should avoid more modern editors, but to assert that either is completely worthless misses why people would continue to use either in the first place.

Some First Impressions of Nix

Ryan Faulhaber — Sat, 29 Aug 2020 02:50:35 +0000

In my relatively few years of software development I've seen first hand how hard it can be to set up a consistent environment, development or otherwise, across a team, and I think Nix might be a solution.

Docker is notably a solution for this: rather than bring everyone's environments up to speed, Docker brings the environment to you in the form of containers. Since Docker containers are deterministic, you also know that if your application works on your computer in a container, it'll work on a server in a container. Very handy.

I recently learned about NixOS and the Nix package manager, and it's very appealing to me as a developer and a Linux user for a few reasons. The goal of NixOS and its related software seems to be the ability to create systems and environments declaratively. This may sound like Docker, but unlike Docker, the end goal is your system, not a system apart from your environment.

I've been working with it all for a few weeks now, and here are some thoughts I have.

Nix, the operating system (NixOS)

NixOS is the Linux distro that uses the Nix package manager first class. This is maybe the part of the Nix ecosystem I have the least experience with, as I've only been running it in a VM so far. My goal is to take my current setup in Arch and reproduce it in a configuration.nix file, get that out of the VM, and use it to set up a new NixOS installation. The fact that this is even possible is pretty cool, and with relatively little work I've already gotten a decent amount of my system reproduced (though along the way I've also decided to make a few adjustments, like switch from bspwm to SwayWM).

Nix, the package manager (`nix`, `nix-*`)

Calling Nix a package manager is underselling it, I think, because Nix is unlike any other package manager I've ever used.

For one thing, its usage isn't limited to NixOS, or even Linux: you can install and run packages using Nix on Mac as well. This, it turns out, is very handy on Mac.

On Ubuntu, you might install a package like:

apt install nodejs

On Nix, the equivalent would be:

nix-env -i nodejs

This is not the preferred way to install something, though, because when you regenerate your system's configuration, node won't be there. The only "permanent" packages are those that are specified in your system's configuration. That way, you always know exactly what's installed. The upside to this is that Nix proivdes a way of "trying" packages without letting you commit to keeping them on your system. The downside is that you have to reload your whole system just to permanently install something. A small price to pay, I suppose!

These aspects of Nix also have another upside: rollbacks to a specific state. If you mess up your configuration, as is easy to do in Linux, you can roll back your entire system to a time where it wasn't messed up.

`nix-shell`, the portable environment builder

A brief aside.

The Nix package manager comes with a fascinating tool called nix-shell. Its purpose is also similar to that of Docker: provide a declarative build envronment.

What it does is, according to a shell.nix file or a specific command, it will generate a shell environment suited to that configuration, keeping it separate from the "main" environment.

For example, let's say I want to work on a Node project. I could run the following:

nix-shell -p nodejs

After some output to the terminal, I'm dropped into a new shell environment where node is now an executable. This way, you can specify the tools you need for a particular project without installing them in your main environment. I find this useful for Python, which, for some reason, has always given me a lot of trouble on my Mac.[1]

Nix, the programming language

Finally, Nix is also a programming language. I mean, it is a full blown functional programming language, but it's also kind of a configuration language, or at least had configuration languages in mind while it was designed. Imagine of JSON, YAML, or TOML also had functions and could be evaluated, and that's kind of what Nix is (or at least, how it reads to me!).

A sample piece of Nix configuration, taken from the NixOS manual, looks like this:

users.users.alice = {
  isNormalUser = true;
  home = "/home/alice";
  description = "Alice Foobar";
  extraGroups = [ "wheel" "networkmanager" ];
};

This is part of a larger configuration, and if you're familiar with JSON you can probably imagine what this is setting. What's interesting though is that obviously this configuration actually corresponds to something on your system and would produce an actual user named "alice" with that home directory and those groups, etc.

The language itself isn't terribly complicated conceptually if you're familiar with other functional programming languages, but I have found it hard to get used to. I find it very hard to know what's possible, and I also find it difficult to know what is set where. While writing my configuration.nix file for what'll hopefully be my new NixOS install, I've frequently found myself asking things like "How do I enable such and such setting?" or "When would I need to use mkOption?" I'm sure I'll pick it up in time, though.

Final thoughts

The Nix ecosystem is very fascinating. For as long as I've been writing code I've long wondered how to consistenly reproduce developer environments, and I think if Nix isn't a full blown solution to this problem, it seems on track to being one. I'm very eager to learn more Nix!

Cool Emacs Things: Editing Files over SSH

Ryan Faulhaber — Sat, 22 Aug 2020 18:59:41 +0000

This is the first installment of an indefinite series calling (in lieu of a better name) “Cool Emacs Things,” little things about Emacs that makes it a very handy editor.

Today’s entry: Editing files over SSH.

This was something I discovered recently by accident. I run a private email server and the IMAP portion of the server is handled by Dovecot. Dovecot is great but by default the configuration is spread across dozens of files, and, while trying to tediously edit multiple files over SSH in Vim, I thought, “Wouldn’t it be nice if I could do this with Emacs?” Well guess what!

C-x C-f (or SPC f f in Doom, which is what I use) will open a “find file” dialog, obviously letting you open files and peruse your file system. However you don’t have to just browse for files. I use Ivy, so your experience may vary, but when I type /ssh: TAB I’m shown a list of my SSH connections. /ssh:ryan@email-server:/ then will cause Emacs to presumably run some commands using SSH (or a related program) and treat it as a directory on your own computer. You can then used Dired (like an interactive ls, if you aren’t an Emacs user!) to explore your remote files and folders and even open files and edit them.

The Emacs package that handles this is called TRAMP, and allows you to do a lot more than just what I’m talking about in this post.

There is one issue with this, however: my Dovecot configuration requires root permissions to edit them. TRAMP can handle this too with something called multiple hops. The idea is that I’ll first connect to the host via SSH and then run any further commands using doas (the OpenBSD equivalent of sudo more or less, as my email server is hosted on OpenBSD).

The final command to do all this looks like:

/ssh:ryan@email-server|doas:ryan@email-server:/

Now I can browse and edit my email server with elevated permissions. Cool!

Writing an Emacs module in Rust

Ryan Faulhaber — Sat, 15 Aug 2020 02:31:19 +0000

I'm a new Emacs user. I made the jump to Emacs from VSCode / IntelliJ / Vim back in March, and it's been a mind-blowing experience. I cannot sing Emacs's praise enough, it's a truly incredible piece of software.

I'm also a new Rust developer. I don't write Rust professionally but I made my way through the wonderful and informative Rust book and I fell head-over-heels for this language. I never thought of myself as having any interest in systems programming until I learned Rust, and Rust has allowed me to very easily bridge that gap.

So recently I learned that Emacs allows you to write dynamically-loaded modules written in C. In case you don't know, if you want to customize Emacs, you must write Emacs Lisp code. This is no different than if you want to customize VS Code and writing JavaScript or TypeScript, although Emacs Lisp is far more robust in terms of what it will allow you to customize. Not all Emacs Lisp code is written in Emacs Lisp, though. Some functions that have to interact with the system on a lower-level are written in C but can be called like Emacs Lisp functions. Emacs also lets you write such functions yourself.

I would hardly consider myself an expert in the fields of C or systems programming, but I've always wanted a good excuse to mess around with rust-bindgen. I also realize there's already Emacs bindings for Rust, but for the sake of learning we'll ignore that for now.

Here's how I tried to write a module for Emacs in Rust.

How it works

According to the Emacs documentation on the matter, if we were writing C, writing an Emacs module requires the following steps:

Include the emacs-module.h header file
Specify int plugin_is_GPL_compatible; in your code
Implement the emacs_module_init function, which Emacs will call upon loading our module

And that's pretty much it. But obviously we're dealing with Rust, so our plan of attack will instead be to generate bindings using rust-bindgen and implement our init function in Rust.

Setup

I started this like I begin all new Rust projects: by calling cargo new --lib emacs-module-test.

My Cargo.toml file was edited to contain the following:

[package]
name = "emacs-module-test"
version = "0.1.0"
authors = ["Ryan Faulhaber <faulhaberryan@gmail.com>"]
edition = "2018"
# let's make our code GPL-compatible!
license = "GPL-3.0-or-later"

[lib]
path = "src/lib.rs"

# we need to specify "cdylib" because our project has to output a shared object
# file
crate-type = ["cdylib"]

[dependencies]
# we'll need some help from libc to interact with C's types
libc = "0.2"

[build-dependencies]
# and of course we'll need bindgen
bindgen = "0.54.1"

Next, we'll a build step, as per bindgen's instructions:

// build.rs
extern crate bindgen;

use std::env;
use std::path::PathBuf;

fn main() {
    let bindings = bindgen::Builder::default()
        // I just imported it straight from where it was on my computer.
        // If we were building a real module we might not want to do this!
        // Also if you're trying this on macOS this header file may not be
        // in this particular location
        .header("/usr/include/emacs-module.h")
        // We want to specify our own emacs_module_init function, so we won't
        // generate one in Rust automatically
        .blacklist_function("emacs_module_init")
        // Generate the bindings
        .generate()
        // Explode if something goes wrong
        .expect("Unable to generate bindings");

    let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
    bindings
        .write_to_file(out_path.join("bindings.rs"))
        .expect("Couldn't write bindings!");
}

This is mostly lifted straight from rust-bindgen's documentation.

Finally, we'll start the lib.rs file:

// this is also borrowed from rust-bindgen. C code obviously has different
// stylistic conventions. For the sake of simplicity we'll write stylistically
// unconventional code
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]

// this dumps the contents of bindings.rs into this file upon compilation
include!(concat!(env!("OUT_DIR"), "/bindings.rs"));

So far so good. The project should compile (cargo build) without issues. This would also be the time to drop a copy of the GPL-3.0 license into a file called LICENSE.

Looking through `bindings.rs`

Before we get started we should take a look at the bindings that rust-bindgen generated. The path will be something different for you, but to give you a sense of where to look, the path on my machine was: target/debug/build/emacs-module-84a415ae9d763afd/out/bindings.rs

There's a few types that we should make note of.

`emacs_runtime`

In the code we'll be writing Emacs provides us with an instance of this struct that represents the Emacs runtime, so we don't have to worry about creating it (I would be interested in mocking it though…). The most important part of this struct is the get_environment member, which is a function pointer. As the signature implies it returns an instance of emacs_env, so let's check that out.

`emacs_env`

Since I'm running Emacs 26 there are two version of this struct. I'm only concerned with emacs_env_26.

This is the more important struct, as a number of its members are function pointers to crucial functions we'll need to interact with Emacs. I won't go over them all now, but the ones that we'll be using are:

make_function, which creates the body of a function
make_string, which converts a string from C (Rust) into an emacs_value
intern, which allows us to create symbols in Emacs
funcall, which allows us to call Emacs functions and receive their return value

`emacs_value`

This is a representation of a value in Emacs Lisp in C (Rust). It's not entirely clear to me how it works internally, but fortunately it doesn't really matter for what we're doing.

Writing the module

For the sake of simplicity, we'll write a dead simple module, one that's so simple we could write it in Emacs Lisp:

(defun my-message-from-rust ()
  "Returns a message from Rust"
  "Hello Emacs, I'm from Rust")

(defun my-sum (&rest args)
  "Returns the sum of ARGS"
  (apply '+ args))

(provide 'my-rust-mod)

Our module will provide two functions, my-message-from-rust and my-sum. The former simply returns a string literal, while the latter sums up all the values passed to it. That should be easy enough.

As I mentioned earlier, the documentation says that we'll have to implement a function called emacs_module_init. This is where our Rust code will define its functions.

In Emacs, it's conventional to register your module with the list of features available to Emacs. The provide call tells Emacs that 'my-rust-mod is now a feature within Emacs.

Let's at least set up the function first. Our lib.rs file should look like:

#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]

// you shouldn't have to put this at the top of your file, but I noticed that
// rust-analyer got a little confused on my computer when I put it after my code
include!(concat!(env!("OUT_DIR"), "/bindings.rs"));

// we'll be using these later
use std::ffi::CString;
use std::os::raw;

#[no_mangle]
#[allow(non_upper_case_globals)]
// Rust doesn't allow uninitialized static values, and Emacs doesn't care what
// the value of this variable is, as long as it's there
pub static plugin_is_GPL_compatible: libc::c_int = 0;

// ordinarily the Rust compiler will mangle funciton names. we don't want to do
// that, since the C code won't know what code to call.
// we'll also want to use `unsafe` because we need access to raw pointers
#[no_mangle]
pub unsafe extern "C" fn emacs_module_init(ert: *mut emacs_runtime) -> libc::c_int {
    let env = (*ert)
        .get_environment
        // for simplicity's sake we'll be getting a lot of milage out of
        // .expect()!
        .expect("cannot get environment from Emacs")
        // remember, these are function pointers we're dealing with!
        (ert);

    // to be used later
    let make_function = (*env).make_function.except("cannot get make_function!");

    todo!("Finish writing this function!")
}

Now let's write some functions.

`my-message-from-rust`

First, the actual Rust code:

// no need to no-mangle it since it'll never be called by name
unsafe extern "C" fn message_from_rust(
    env: *mut emacs_env,
    nargs: isize,
    args: *mut emacs_value,
    data: *mut raw::c_void,
) -> emacs_value {
    // our actual message
    let s = "Hello Emacs! I'm from Rust!";
    // function pointer to make_string, provided by Emacs
    let make_string = (*env).make_string.unwrap();
    // converted to a CString
    let c_string = CString::new(s).unwrap();
    // grab the size in bytes, as needed by Emacs
    let len = c_string.as_bytes().len() as isize;
    // return the emacs_value returned by make_string
    make_string(env, c_string.as_ptr(), len)
}

Now, let's return to our init function and add the following:

let my_message_func = make_function(
    // a reference to our Emacs environment, of course
    env,
    // min_arity argument
    0,
    // max_arity argument
    0,
    // our actual function
    Some(message_from_rust),
    // docstring, so users can check the documentation for this funciton in
    // Emacs
    CString::new("This will print a nice message from Rust code!")
        .unwrap()
        .as_ptr(),
    // data argument. we are not passing this function any additional data, so
    // we give it `null`
    std::ptr::null_mut(),
);

What's important to note about what we're doing here is that we're creating a new function value. Functions in Emacs Lisp (and indeed any functional programming language I've ever heard of) are just values, like integers or strings. Much like our call to make_string earlier, we're just creating a new value on Emacs's terms. In fact it's probably more like creating an anonymous function. If this was the only code we wrote, our users would have no way of calling our code from within Emacs. We'll get to that later, though.

`my-sum`

This one is a bit more interesting because we want our function to accept an indefinite amount of arguments. The actual function code:

// again, no need to no-mangle
unsafe extern "C" fn my_sum(
    env: *mut emacs_env,
    nargs: isize,
    args: *mut emacs_value,
    data: *mut raw::c_void,
) -> emacs_value {
    // Emacs provides us with a way of grabbing an integer value out of an
    // emacs_value object
    let extract_integer = (*env)
        .extract_integer
        .expect("could not get extract_integer");

    let mut numbers = Vec::new();

    // Emacs is kind enough to tell us how many values were passed to our
    // function, so we don't really have to worry about whether or not the size
    // of `args` is the same as `nargs`
    for i in 0..nargs {
        // pointer arithmetic! how unsafe!
        numbers.push(extract_integer(env, *args.offset(i)));
    }

    // some good old Rust iterators
    let sum = numbers.iter().fold(0, |acc, n| acc + n);

    // again, we have to rely on Emacs to convert to the proper type
    let make_integer = (*env).make_integer.expect("could not get make_integer");

    make_integer(env, sum)
}

And again, we have to register it with the system in a similar way to our other function.

let my_sum_func = make_function(
    env,
    0,
    // this is a special value provided to us by Emacs letting it know that we
    // want our fuction to accept an indefinite amount of arguments
    emacs_variadic_function as isize,
    Some(my_sum),
    CString::new("Sums a series of integers")
        .unwrap()
        .as_ptr(),
    std::ptr::null_mut(),
);

Finishing up module init

As I mentioned earlier, we have to associate our new function values to names in order to call them. At the moment they're sort of floating out in the ether with only memory addresses to reference them, and that's not particularly useful.

First, we need some symbols to associate to these functions. A symbol in Lisp is more or less just an identifier, but in order to create them they must first be interned. This is where we can use the intern function.

Let's add the following to our init function:

let intern = (*env).intern.expect("could not get intern");

// creates "my-message-from-rust symbol"
let my_message_sym = intern(env, CString::new("my-message-from-rust").unwrap().as_ptr());
// creates "my-sum"
let my_sum_sym = intern(env, CString::new("my-sum").unwrap().as_ptr());

Next, we'll need to associate our functions with said symbols:

// intern will return a symbol if it's already defined.
// we're going to use `fset` to associate our functions to symbols
let fset = intern(env, CString::new("fset").unwrap().as_ptr());

// we also want to actually call fset, so we'll need funcall
let funcall = (*env).funcall.expect("could not get funcall");

// in Emacs Lisp this is like:
// (fset 'my-message-from-rust (lambda () ...))
funcall(env, fset, 2, [my_message_sym, my_message_func].as_mut_ptr());
funcall(env, fset, 2, [my_sum_sym, my_sum_func].as_mut_ptr());

Finally, we'll want to provide our new feature:

let provide = intern(env, CString::new("provide").unwrap().as_ptr());
let feat_name = intern(env, CString::new("my-rust-mod").unwrap().as_ptr());
let provide_args = [feat_name].as_mut_ptr();

// equivalent of (provide 'my-rust-mod)
funcall(env, provide, 1, provide_args);

// and finally, we can return from this function!
0

Does it work?

Let's run a cargo build to make sure everything at least compiles.

Rust should give us a file called libemacs_module.so in target/debug (or libemacs_module.dylib if you're on macOS) assuming your project name is called emacs_module. There are a few ways of trying to run our code:

Open Emacs, run (module-load "path/to/your/libemacs_module.so"), and running the functions yourself

From the terminal, running:

emacs -Q -l path/to/your/libemacs_module.so --batch --eval '(message "%s" (my-message-from-rust))'

Either way, the functions you defined in Rust should now be runnable from Emacs.

Things I couldn't figure out

This article was written based on my own experience and process of writing the example code I've walked you through. There's a few things, though, I don't understand about what I've done:

If I compile this with cargo build --release, I suddenly get type errors from Emacs. I suspect it's a configuration error but as of the time of writing this I'm not sure what the issue is.
I'm not sure how you'd write an interactive function, if at all.
I'm not sure how you'd deal with more complex data types, like alists. How would you create them or manipulate them?
There's quite a bit of verbose CString construction happening. I found that if I put that behind a function I suddenly get segfaults. I'm not sure why.
Similarly, refactoring this code to make intern its own Rust function leads to segfaults.

What's the point of all this?

If you've never used Emacs before and you've read this whole thing, you might realize that Emacs isn't exactly a normal editor. It's not every day we're compiling and linking code to our editor. But why would we want to do this? Here are two reasons I can think of:

Performance. Emacs Lisp is often good enough (at least, in my experience) but for more significant computation it might not be a bad idea to offload that to Rust code.
Further extensibility. Emacs is already very extensible, and Emacs has decades of history behind it. Emacs Lisp can do a lot language-wise, but it has its limits. Code written in Rust (or even C, of course) wouldn't have such limits.

In any event, I just think it's a pretty handy feature to have. Maybe in the future I'll be writing a more extensive dynamic module for Emacs (though I think I'll stick to using emacs-module-rs)!

If you want to see the full code, you can check it out here.

You Should Try Linux

Ryan Faulhaber — Thu, 06 Aug 2020 01:55:24 +0000

I’ve been using Linux since about 2013 and it’s been a consistently rewarding experience. Not only am I far more productive on Linux than I am on macOS or Windows, I have the satisfaction of using a system that’s uniquely mine.

When I first started using Linux I was beginning my computer science education. I had a consistent problem with the tools the classes I was taking called for. It always seemed like there were normal install instructions, and install instructions for Windows (I had a big clunky Windows laptop at the time). The computer lab had all the software I’d need but it was a pain to always be going to the computer lab to get my work done. It just so happened that my dad, who works in IT, had a customer give him an old Dell laptop and he told me I could have it if I wanted it. It didn’t come with a Windows license so I had to make do. I installed Ubuntu onto it and started down the Linux journey I’m on now.

If your daily driver is macOS or Windows, I want to try and convince you to at least try Linux.

Linux is easier to use than you think

A lot of people I’ve talked to avoid Linux because they hear it’s hard to use. It doesn’t support x piece of software or y isn’t compatible with it. Sometimes those are fair points, and sometimes Linux does require you to adjust how you do things. For example, if you’re locked into Office 365 and don’t want to switch, Linux indeed will probably not be much help in this case.

However, if you’re flexible in the software you use, Linux can provide alternatives to a lot of software that isn’t supported on it (instead of Microsoft Office you could use LibreOffice. I know it’s not the same but for being free and open source it’s very fully featured).

Installing Linux can also be pretty simple. The more well-supported distros have graphical installers that don’t require a ton of technical knowledge (a distro is “flavor” of Linux: each distro comes with the Linux kernel but might provide a different user experience. Ubuntu, Debian, Mint, and Arch are all distros). Of course, if you wanted to get into the nitty-gritty of Linux installation, there are ways of going about that too.

Linux is everywhere

Linux is the world’s most used operating system in every domain except for desktops (that honor belongs to Windows). If you choose to use a Linux desktop, the skills you learn by using and customizing your desktop are things you can take with you into other domains. When I first started learning how to use AWS, I wasn’t intimidated at all by EC2 because I knew it was just a Linux server of some kind. When AWS told me how to set up my SSH keys, provision and update my server, and so on, this was all stuff I already had a sense of how to do, just because I was already doing a lot of that stuff on my desktop!

Linux comes from the Unix tradition (kind of)

If you’re a Windows user, you honestly have no idea on what you’re missing out on in this regard.

Linux is not a Unix, but it was designed to be a clone of Unix. This means that there’s a lot of crossover (at a certain level) between how things work on Linux and how things work on Unix systems (Unix systems include any of the BSDs and macOS). The terminal experience, for example, will for all intents and purposes be nearly the same. It’s not until you get into the lower level details that things start to make a difference (fun fact: the ls program has different implementations between Linux and Unix, though they behave similarly).

I had never used macOS until I got my first job, where they asked me if I’d rather have a Windows laptop or a Macbook. I chose a Macbook, opened the terminal, and felt mostly at home.

Linux is yours

This, to me, has become the main selling point. I have a Macbook, I have a Windows partition on my computer, but the reason why I keep using Linux most of the time is because my Linux desktop is uniquely mine.

I mean this both in terms of the customization and maintenance of my system. I’m an Arch Linux user (maybe soon-to-be NixOS user?) and one of the things I’ve come to value about Arch is that, if I’m willing to put in the work, I can make my system look and feel pretty much however I want. I’ve become enamored with tiling window managers.

With Windows and macOS, although they may have their merits, the way you interact with them is largely at the whims of Microsoft and Apple respectively. If you don’t like what Apple decided to do this year with macOS, too bad! With Linux, you are not stuck to such a fate.

If you’re willing to put in the work and learn how to do it, customizing your system exactly how you want can be very rewarding. It’s a trade-off though: you must put in the time and learn the skills to do it. You’ll likely learn a lot doing it along the way, though. If you feel so inclined you can look for inspiration from r/unixporn, where users show off their system customizations.

How can I try Linux?

If you’re just starting out with Linux, I’d recommend one of the more well supported distros, like Ubuntu or Linux Mint. I’ve also heard good things about Elementary, Pop!OS and Fedora, although I’ve never used any of those. If you rely on graphical software especially these distros will make the transition easier.

To get a good sense of what’s out there, Distrowatch has information on nearly every distro out there that you could think of, and has links to where to find more information about particular distros. If you don’t want to commit a partition of your hard drive to it, you can also always try it in a VM.

How can I learn Linux?

I think I’ll be putting out a series of posts with the intention of teaching people how to use Linux from an absolute beginner’s perspective, so watch my feed!

Back when I was getting started with Linux I read Learn Linux The Hard Way, which served as a wonderful introduction to Linux overall (the site seems to have since been taken down, but it can be accessed through that archive.org page). In the meantime, this should serve as a good crash course.

Aside form the book above, I learned Linux two ways:

Starting with the question “How can I do this more efficiently?”, doing some Googling, and learning about all kinds of things I didn’t know before.
Doing as much as possible in the terminal
Seeing other people’s dotfiles

With Linux comes a tradition of nearly 30 years of computing, and over the course of that 30 or so probably every problem you can think of as an individual has been solved. If you think there’s an easier way to do something in Linux, there probably is, but might involve writing a script.

Lessons Learned from Functional Programming

Ryan Faulhaber — Sun, 02 Aug 2020 20:53:10 +0000

When I went to college the majority of my programming classes were taught with Java. As a result I learned what I like to call "classical" object-oriented programming. As I started writing more JavaScript I realized I had a lot of issues importing the OO lessons I learned. At some point I read Kyle Simpson's Functional-Light JS and my whole world turned upside down. From there I dove into the world of functional programming and internalized many of the lessons I learned. I write JavaScript completely differently now, and I feel as though I'm a better programmer for it overall in any language I write. Here are some of the lessons I learned.

Data should be externally immutable

Mutable data generally means data that can be changed. Consider the following JavaScript:

const x = [1, 2, 3]

x[1] = 4;

Here we are mutating the x array by changing the item at 1. Many proper functional programming languages do not have a means for letting you do this. Instead, new data is derived. In functional programming, the equivalent code would basically do this:

const x = [1, 2, 3];
const y = [...x.slice(0, 1), 4, ...x.slice(2, 3)];

That is, it copies every element except the one we want to change, and return a new array.

Why is it important?

In languages that have implicit referencing (e.g. Java, JavaScript), having functions that mutate objects can lead to confusing and hard to trace code. For example:

function changeFirst(arr) {
    arr[0] = 'first';
}

const x = [1, 2, 3];

changeFirst(x);

If you were working in a large codebase, and you didn't happen to know what changeFirst did, this could lead to potentially confusing code. If changeFirst treated x as immutable, you'd know that after x was passed to it you wouldn't have to worry what the value is. This, I think, would be clearer:

function changeFirst(arr) {
    return ['first', ...arr.slice(1)];
}

const x = [1, 2, 3];
// --- don't have to worry about x after this point ---
// (unless we need to derive more data from it of course)
const newX = changeFirst(x);

And of course by externally mutable I mean that a function should be free to mutate data within itself, but should not mutate a function's arguments or anything in the outside world.

Functions should reduce side effects

A side effect is when a function modifies some value outside of its current scope. Contrary to popular belief, though, side effects are not in themselves bad, nor are they necessarily hidden. Side effects do tend to create code that's harder to reason about, though.

Kyle Simpson's chapter on side effects in JavaScript is wonderful, but I'll try to do it justice here.

Unfortunately, object-oriented languages have side effects baked into their design, and I think that's part of the reason why there's so much literature written around "clean code" and things like that.

For example, consider the following Java code:

public class Foo {
    private int number = 0;

    public void inc() {
        number++;
    }
}

In this case, a call to Foo's inc method produces a side effect of modifying an instance of Foo's state. See what I mean when I say they're baked in?

Again, though, this isn't to say that they're bad. The problem with this code though is that it's not immediately obvious what's happening to the outside.

An example in JavaScript would be the following:

let x = 1;

function doSomething() {
    x++;
}

doSomething here modifies x, which is definitely outside of the scope of its function.

Why is it important?

The Wikipedia article on side effects mentions some interesting concepts: referential transparency and idempotence.

Referential transparency is simply when an expression is written in such a way that you could replace the expression itself with its resulting value. Consider the following:

function add(x, y) {
    return x + y;
}

const number = add(2, 3);

add is referentially transparent because we could replace its call with the number 5 and it would make no difference to the behavior of our program.

Idempotence is similar. It can be thought of as having a similar definition to "deterministic." An idempotent function basically means that you can call the same function more than once with the same arguments and achieve the same results. The best example is REST endpoints, where a lot of REST API callouts are expected to do the same thing. An API call like GET /user?id=123 would be expected to return a specific user. You could call that endpoint a hundred times and it would do the same thing.

I think these two concepts, above all else, help with making code readable and reasonable. If we know our functions have little side effects and always do the same things, we can spend less time worrying how they effect the system.

In general, reducing side effects requires some discipline, especially in OO languages. I try to stick to writing functions that operate only on their function parameters as much as possible and return a value somehow derived from the arguments. This way I hope to write more predictable and deterministic code.

Classes aren't always necessary

This was a hard thing for me to (un-)learn while learning JavaScript (and subsequently newer languages that aren't strictly OO, like Go and Rust).

One of the problems with learning Java or C# as your first language (Java was mine), I tend to find, is that it forces you to think of problems in terms of object interactions. Java and C# don't give you much option in this regard: your entire application has to be expressed in terms of classes, so you have to use them. This, to me, is the fatal flaw of both languages. Not all problems necessitate classes.

In languages such as JavaScript where you don't have to express everything in terms of classes, where is the line drawn? For me, it's a question of statefulness. Does the part of my application I'm currently working on need to keep track of anything directly? In writing JavaScript, I find that a majority of the time it usually does not.

In JavaScript, there are mainly two types of classes I create:

Component classes. If I'm writing React, for example, and I find that I need a stateful component, I will declare it as a class. Otherwise it's a function.
Useful types. I don't create these often but sometimes you find yourself needing to collect data in a way that standard objects don't allow for. If I were writing a parser for example, the parser itself would probably be a class.

The rest of my code lives in functions.

In statically typed languages, there's a third type of class I'd create: what the programming language Kotlin calls "data classes." A data class is just a class that wraps data and has no internal logic to it. It's a class with all public fields that is meant to take advantage of a language's static typing. Such classes tend to be things like REST API requests or responses.

In conclusion

The above are all lessons I've learned from not only reading about functional programming but trying to learn functional languages. Functional programming languages are different than what most people are used to, I think, but they also offer a different way of thinking about programs, even if most of the time we can't write programs functionally.

I don't write purely functional JavaScript, but I've tried to import the lessons I've learned from functional programming where possible to make my JavaScript clearer. JavaScript can be confusing as it is and it doesn't need any help in that regard, but I feel that trying to write more functional code as made my JavaScript clearer.

Ways Emacs Has Changed What I Do

Ryan Faulhaber — Fri, 24 Jul 2020 03:09:16 +0000

Previously I had written about trying Emacs, but looking back on that post I felt like I was bit vague about the ways in which it’s changed the things I do, so I wanted to provide some examples. Emacs has replaced a number of programs in my life, and not all of them are developer related.

Programming

If you can believe it, this is maybe the most underwhelming part. Don’t get me wrong, though! Emacs is a great editor obviously, and it has all the conveniences of a more modern editor and much more. I did want to talk about what it’s like to write code in Emacs though, briefly.

Being a web developer I write a lot of JavaScript, and as you’d imagine there’s a bunch of extensions in Emacs for writing JavaScript. Emacs has a package called quickrun that can evaluate code in buffers on the fly.

As someone who sometimes needs a reminder on the particularities of how certain JavaScript methods work, this is very useful!

Journaling

I’ve always wanted to get into the habit of journaling. For the last few years of my life I’ve been through a couple of journaling apps, some of which I’ve paid for! Bur for whatever reason I could never get into the habit. I’d start out strong and then stop a week or two in, only to sporadically update.

With Emacs, I’ve been journaling almost every day for the last two months or so, and it’s all thanks to org-journal (I also think it has something to do with the fact that my journal and all my other Org documents live in the same place, and that Emacs provides a very convenient way of creating new journal entries).

Blogging

The biggest benefit of Org mode, like Markdown, is that it’s a format that can be easily translated into another format. ox-hugo, an Org exporter geared towards converting Org documents into Hugo-compatible Markdown files, is now what I use to manage my blog. Blogging is new to me and I only have a few posts under my belt, but almost all of them have been written as Org documents and exported via ox-hugo (or just as GitHub-flavored Markdown when I post the same thing on dev.to).

Note-taking

This is the biggest change.

A lot of what I read could be called academic. Before Emacs I had used Evernote, Notion, Trello, physical notebooks, and other apps that I’m probably forgetting to take notes. For some reason it had never occurred to me to take notes as plaintext (I never took notes as Markdown files), but when I learned about Org mode, it seemed natural that I’d use it to take notes.

But Emacs let me take it one step further.

I had been reading about Zettelkasten and learned about Roam Research. The idea of having a flat note hierarchy with links between all your notes (structurally similar to but functionally different than a Wiki) was immediately appealing to me. Of course, because the Emacs ecosystem is so fully featured, there’s a package for that: org-roam, which is truly a marvel of an Emacs package.

Although I’m still in the process of figuring out how the Zettelkasten method can work with a Roam-like system, I’ve already taken extensive notes using org-roam: my org-roam directory currently sits at 323 files, though not all of those files have content.

Email

I never thought I’d be this person. When you hear about people “living” in Emacs, this is just part of what they mean.

I host my own private email server (for a guide on how to do this yourself, I strongly recommend this one. It’s the one I used), and I’ve never found a great or consistent email client for the desktop. The closest I came was Mailspring, which, although it is nice, it’s a bit slow for what it is.

When I first started learning Emacs, I knew you could check your email with it. mu4e will let you do this. You can read, manage, and send email all from Emacs. You can even write emails as Org documents! It’s surprisingly easy and consistent to use. It’s best used when your emails are plaintext, but that’s generally true too.

And plenty more…

Emacs has changed a lot of what I do in a lot of small ways that I can’t really count. It’s really a wonderful program, and I can’t believe how much I’ve come to really love using it. Every day I feel like I’m learning something new about it, and it’s all such a joy to use! As I said in my last post, you really should give it a try.

You Should Try Emacs

Ryan Faulhaber — Mon, 13 Jul 2020 19:59:38 +0000

No, really, you should try Emacs. I gave it a shot a few months ago and now I’m hooked.

I know Emacs isn’t the most trendy thing these days, in fact it seems that VS Code is the new hotness. But Emacs deserves your attention.

Let me start by telling you how I arrived at Emacs: some time ago I used IntelliJ for work, almost exclusively. IntelliJ is great, honestly. You can do a lot without having to leave the editor, which I came to realize was something I wanted from an editor.

Some time later I switched to VS Code, and I switched for a lot of little reasons: there were a lot of plugins, the editor looked nice, the editor was more lightweight than IntelliJ, some languages I used were better supported. VS Code is also great.

Then I learned Vim, and that’s where I think the real journey to Emacs began. At first I just learned Vim keybindings (press i to enter “insert mode”, press viw to highlight a word, etc.), and fortunately the Vim plugins for VS Code and IntelliJ supported most of what I needed to do. But whenever I’d use Vim proper in the terminal, I always realized it could do a lot more, and the thing I started to realize was that I wanted all those features. The Vim plugins for VS Code and IntelliJ are, for all intents and purposes though, black boxes. Sure you could open a PR and implement some feature yourself, but why bother when Vim itself has those features? Or so was my reasoning.

So for some time I switched between three editors to get various tasks done, but I still felt it wasn’t enough. I felt all three missed something, but I couldn’t quite articulate what.

Then I learned about Acme, the editor from the Plan 9 operating system, and my mind was blown. Acme wasn’t without its own issues, sure, but the idea that the editor itself should require almost no additional work from the user in order to gain extra features was incredible to me. In Acme, you don’t need a built-in editor command to sort a bunch of lines. Instead, you can pipe your lines through Unix’s sort command and pipe the output back into the editor. Acme was as extensible as your own system was.

Unfortunately, using Acme was somewhat unfeasible. I really needed syntax highlighting and Vim keybindings (once you learn them they’re very difficult to forget, and you tend to want to use them everywhere!), and that was a showstopper for me.

Enter Emacs. Someone I know who was a Vim user made the switch to Emacs and was telling me how incredible it was, and at first I was skeptical. I thought Emacs was some old dusty program from the 70s that was as arcane as something like Prolog. Plus I had tried the tutorial years ago, and I thought the keybindings were weird. I was assured, though, that Emacs had a plugin called Evil that could emulate Vim keybindings, and maybe even better than VS Code or IntelliJ (spoiler alert, it does). “Very well,” I thought, “It wouldn’t hurt to try.” I was not prepared for what Emacs had to offer.

Four months in and Emacs is now the only editor I use. I will say though, in the beginning, Emacs was extremely daunting. It was maybe the second hardest editor to learn after Vim (Vim took me a good month before I was productive with it). What is most daunting about Emacs though is why it’s taken over my life: it’s infinitely extensible.

You may be skeptical. You might think “Well VS Code is extensible!” Indeed, it is. But Emacs is extensible to a degree that’s easy to underestimate. For all intents and purposes, Emacs is a Lisp machine. Emacs, much like your browser, provides an entire platform upon which functionality can be built. In your browser’s case, that functionality is written in JavaScript. In Emacs, it’s Lisp (specifically Emacs Lisp). Moving the cursor in any direction, for example, is a binding between a key press and a Lisp function.

I’d argue that extensibility and customizability are crucial for productivity. Everyone is different and as such I imagine we all use our computers a bit differently. Emacs is extremely accommodating to whatever your workflow is, provided you’re willing to put in a bit of effort to customize Emacs.

In some ways, Emacs is the equal but opposite of Acme. Emacs provides a lot of tools. But unlike an editor like VS Code, editing Emacs is as easy as opening a new buffer (a collection of text that may or may not correspond to a file), writing some Emacs Lisp, evaluating it on the fly, and with just a few lines of Lisp you have a new plugin.

I’ve emphasized Emacs’s extensibility thus far, and I think that should be its main selling point. Emacs is so extensible that there are pre-configurations of Emacs to make it look something like VS Code (Doom Emacs is wonderful. It’s what I use and what got me into Emacs). It’s so extensible that it can be used as an email client and Twitter browser. And what’s incredible about all these extensions is that Emacs will carry all your configuration and keybindings around to all these different contexts. If you’re a Vim user, being able to do things like check your email or use Emacs’s Git client with Vim keybindings is wonderful.

(Side note: I never actually used a Git client before using Emacs. Magit is maybe the only one I could ever see myself using.)

And lest I forget, Emacs also has something called Org mode. For a more comprehensive introduction, I recommend this video. Org mode on its surface can be thought of a more feature-complete Markdown: it’s a plaintext syntax that is designed with the intention of rendering as something else, including but not limited to HTML. However Org mode in its own right is very powerful because it’s backed up by Emacs. Org mode documents can be used as interactive todo lists and agendas. Like Markdown, Org mode supports source code blocks. Unlike Markdown (at least inherently), Emacs can actually evaluate Org source code blocks for some supported languages. You can use this to write documentation to, for example, illustrate what some block of code prints to the console. Or, since Org mode can evaluate Emacs Lisp, you could write your entire Emacs confugration as an Org document.

So, if you’re in the business of text editing, and you’re used to having to fine-tune configuration to get the exact outcome you want, I strongly suggest at least giving Emacs a try. I feel like Emacs is an often forgotten about editor, and I think it deserves a shot.

Do you use Emacs, or have you ever used it in the past? What do you think about it?

I'm a software developer working in full-stack web development. I'm also interested in systems programming, programming languages, and computer science in general. Follow me on dev.to and Twitter, and check out my site and GitHub!

Forem: Ryan Faulhaber

Cool Emacs Things: Evil

Cool Emacs Things: Dired

Quest for a Better Scripting Language

The Goal

Bash

Python

Ruby

JavaScript

Emacs Lisp

Conclusions

Honorable mentions

Perl

AWK

Lua

Tcl

Koi

Footnotes

Cool Emacs Things: Magit

Critique of the Magic of Modern IDEs

What is an IDE?

The So-Called Magic of IDEs

The Cold Vim/Emacs War

Why use Vim or Emacs?

Some First Impressions of Nix

Nix, the operating system (NixOS)

Nix, the package manager (nix, nix-*)

nix-shell, the portable environment builder

Nix, the programming language

Final thoughts

Cool Emacs Things: Editing Files over SSH

Writing an Emacs module in Rust

How it works

Setup

Looking through bindings.rs

emacs_runtime

emacs_env

emacs_value

Writing the module

my-message-from-rust

my-sum

Finishing up module init

Does it work?

Things I couldn't figure out

What's the point of all this?

You Should Try Linux

Linux is easier to use than you think

Linux is everywhere

Linux comes from the Unix tradition (kind of)

Linux is yours

How can I try Linux?

How can I learn Linux?

Lessons Learned from Functional Programming

Data should be externally immutable

Why is it important?

Functions should reduce side effects

Why is it important?

Classes aren't always necessary

In conclusion

Ways Emacs Has Changed What I Do

Programming

Journaling

Blogging

Note-taking

Email

And plenty more…

You Should Try Emacs

Nix, the package manager (`nix`, `nix-*`)

`nix-shell`, the portable environment builder

Looking through `bindings.rs`

`emacs_runtime`

`emacs_env`

`emacs_value`

`my-message-from-rust`

`my-sum`