I have a certain philosophy to the software that I use. I strive to do more than just describe one program as
worse than another, but to actually analyze the details behind those gut feelings:
- What makes me prefer one program over another?
- Why would I describe something as
better? What is the underlying philosophy or design goal that makes me like the software?
As such, I try to codify my values into a coherent view of the software world. I do this not only so that I know what I want, but also how to build things that I would like to use.
I prefer to use software that gives me freedom, because I care about having ownership of the tools I use every day. Occasionally I fix things and send patches, and I think that process is important in fostering a community among software developers.
Besides, I wish to own my software in the same sense that a writer owns her typewriter. If it breaks, she will fix it. She understands the mechanics of the machine, so that she can diagnose problems and fix them. There are no laws governing whether or not she may disassemble the typewriter. These are fundamental properties of ownership of everyday objects: they afford that a sufficiently adept individual may master her tools.
In alignment with the Arch Linux philosophy of simplicty, I prefer software that I can understand. The more open and obvious your software is, the more I appreciate it for what it does. Simple things connect well with other pieces of software - that’s the basic philosophy of the GNU core toolkit, and it applies to most other software you may find.
As such, I try to avoid a desktop environment like Gnome or KDE. I find they’re not really necessary for me to use my computer - I spend most of my time hopping between terminals, a text editor, and a web browser anyway. I need software that lets me do that as efficiently as possible.
A corollary to the fact that simple things connect well with other software is that simple software is more easily scriptable. People accustomed to writing software understand that automating tedious tasks is one of the reasons it is a useful skill. Think of Git and all the wonderful tools people have built on top of it. The reason it is so easy to build things on top of Git is the fundamental simplicity of its data model and the programs that talk to it. The language might be difficult at first, yes, but from a technical standpoint Git is conceptually simple, both in design and execution.
I prefer software that is fast. Of course, ceteris paribus, everyone will agree with me on that. But there are many tradeoffs made in software development, and among the most important decisions is how you manage performance.
This doesn’t just mean software should be fast to run. Maybe it should be fast for the user, or more efficient to use, at the cost of being somewhat less performant.
Performance is like money. It’s like currency. So you say,what good does a stack of hundred dollar bills do for you? Wouldn’t you rather have food, or water, or shelter, or whatever?And you’re willing to pay those hundred-dollar bills for that commodity, even though water is far more important for your living. Similarly, performance is what you pay for user-friendliness. It’s what you pay for security. You hear people sayI want greater functionality- so people will program in Java, even though it’s much slower than C. And they’ll sayit costs me maybe a factor of 3 or something to program in Java, but Java’s worth it because it’s got all these object-oriented features and so forth, exception mechanisms, and so on.And people are willing to pay a factor of 3 in performance. So that’s why you want performance: because you can use it to pay for these other things that you want.
I prefer software that makes smart decisions about this time tradeoff. Oftentimes, the right way to go for me as a user is to just write software that is fast and simple, and then I will make it do what I need.
In college, I used Linux exclusively. Now I run Arch on my home laptop and dual boot OS X and Arch Linux on my work Macbook Pro.
I use both Emacs and Vim, which is an odd combination to hear someone mention.
- Emacs: I have a post about my Emacs configuration here.
- Vim: I started using Vim in early 2012, long before Emacs. I still use it to edit configuration files and make one-off edits, though my primary development has switched to Emacs for its greater featureset.
- vi: used when I edit files as
root, or when I’m installing Arch. Nowhere else.
- Dired sees the heaviest use from me, since I’m usually already in Emacs if I’m doing real work.
- Ranger almost exclusively, but plain shell more often than that. I have a post about it.
- On very rare occasions, I will open Thunar to satisfy Firefox’s
Open containing folderbutton in the download list.
- zsh. Preferable to Bash if you want a modern user interface in your terminal. I still stick to Bash for scripting, of course.
- Zathura is the best PDF viewer I’ve found. It has Vim keybindings by default, is extremely lightweight, and supports multiple backends.
I transcribed more of it than just the quote here. The introduction to that part was:
Ok, so then you can say
why study algorithms and performance?Okay, if it’s at the bottom of the heap. Almost always people would rather have these other things than performance. You go off and you say to someone
would you rather have performance or more user-friendlinessand
more user-friendlinessis almost always more important than performance.
Why do we care? Sometimes performance is correlated with user-friendliness. Nothing is more frustrating than sitting there waiting.
[the class offers suggestions]
So there’s several reasons that I think are important. One is that, often, performance measures the line between the feasible and the infeasible. So we heard some of these things: when there are real-time requirements, if it’s not fast enough, it’s simply not functional. Or if it uses too much memory, it’s simply not going to work for you. So what you find is that often times algorithms are on the cutting edge of entrepreneurship. If you’re talking about just reimplmenting things that other people did ten years ago, performance isn’t that important at some level. But if you’re talking about something nobody has done before, often the reason they haven’t done it is it’s too time-consuming, things don’t scale, and so forth.