Home Of Emacs and Tools

Of Emacs and Tools

For those who aren’t familiar,Emacs is a text eeditor - and much more. First created in 1976, Emacs is built - and extensible - in the Lisp programming language. And this gives it an enormous amount of power. People have extended Emacs to include e-mail and newsgroup functionality, full-featured IDEs for programming, even an outlining solution that’s become a life organizer and document publishing tool.

I’ve been using Emacs on-and-off for decades, and I’ve recently been getting org-mode set up for both organizing my life and for some writing projects. I’ll be blogging more about that, but that’s not what I want to talk about today. Today my thoughts are about the tools we use — hardware, software, and otherwise — and about tool wars. a When I was in college (more years ago than I care to admit) Linux was in its infancy. Home computers were just starting to join the Internet, and a lot of us that used Unix-based computers did so through a command–line interface and a dial-up terminal program. Back then, which text editor you used — Emacs or vi — was a topic of debate, argument, and sometimes holy war.

Though the tech landscape has changed enormously since then, one of the continuing dynamics I still see is people arguing fervently online about which tool is “the best”. Python vs. Ruby vs. CLojure vs. whatever other programming language. Arduino vs. CircuitPython vs. C/C++. The best USB soldering iron. The right soldering station. The perfect 3-D printer and the One True slicing and modeling choices. But I think these arguments all miss the point.

Frankly, I don’t believe there’s One True Choice for any tool. I keep coming back to Emacs because I’ve been using it for nearly 30 years. For me, it’s comfortable, like a well-worn pair of jeans. That doesn’t mean I use it exclusively – I’m fairly comfortable with vi and TextMate and SublimeText too. I think VSCode is fantastic and use it regularly. 3-D modeling software? I have FreeCAD and OpenSCAD and Fusion 360 and use them all.

In short, I’m a big fan of picking the right tool for the job and the user. What does that look like? For me, the right tool is:

  1. The tool that has the capability to do what you need it to. Ideally without requiring you to use it in ways it wasn’t well designed for. You can pound a nail with the side of a chainsaw (but you might break the chainsaw). You can make a tree fall down if you hit it with a hammer enough times. That doesn’t mean those are the right tools for those jobs. This is why my grandfather had so many different hammers and saws in his workshop – he was a big fan of having exactly the right tool for each job.

  2. The tool that gets out of your way. This doesn’t mean it necessarily just works out of the box. I’ve done a lot of tweaking and coding to make Emacs work the way I want it to. But when I’m in the groove, writing a blog post or hacking on code or capturing notes from a meeting? In those moments I don’t want to have to think about the tool. I just want it to enable me to do what I need to.

  3. The tool that you feel comfortable with. This is the big one. I remember being in my Grandpa’s workshop with him as a small child. He was working on something and had a large, heavy hammer out. One I could barely lift. So he had a smaller, lighter hammer in the shop too. That was my hammer, and when I wanted to build something he’d bring it out. He never argued that his hammer was the One True Hammer, that I should just suck it up and use that one. The right tool for me wasn’t the right tool for him – and that’s okay. That’s why there are many different tools.

As I said, I’m going to be doing some blogging about Emacs in amidst my other writings. If you use Emacs, hopefully they’ll be of interest. But if not, if you use other tools you’re happy with? That’s totally fine. Tools are the means to an end, not the end in and of itself. (At least, not unless tool-building is the end you’re working toward).

Use what enables you to get the thing done. At the end of the day, that is the true bottom line.

This post is licensed under CC BY 4.0 by the author.

Thoughts on CircuitPython for 2020

Everything Old Is New Again

Comments powered by Disqus.