Choosing Software

Criteria making software useful long-term & worth learning in detail
Haskell, predictions
2008-09-262012-10-28 in progress certainty: possible importance: 4


There are so many tools one could use, it’s not al­ways clear what soft­ware to pick in the open source world.

For some tasks, the choice is easy since there’s one dom­i­nat­ing play­er—­for web brows­ing you will al­most cer­tainly want to go with Mozilla Fire­fox when in X.org, and ELinks when on the com­mand-line.

But with other ap­pli­ca­tions, the ar­ray of choices is quite as­tound­ing. For an ed­i­tor, Vim or Emacs or… For a shell, do you use Bash, Fish, Zsh, Tc­sh, Ksh, or what? Each op­tion has many com­plex pros and cons, and often par­ti­sans have strong feel­ings about the is­sues.

My­self? I’ve found it use­ful to try and clas­sify all the op­tions by a few con­sid­er­a­tions. Since we’re in­ter­ested in Unix ap­pli­ca­tions, one can safely say that we’re all “power users” and are in­ter­ested in the best we can get. So the first desider­a­tum is that:

Maintenance

  • It should be main­tained.

Life is too short to waste deal­ing with un­main­tained soft­ware. Such soft­ware is prob­a­bly al­ready rid­den with bit rot, and it may well have been aban­doned for a rea­son.

The point of a pro­gram is to make some­thing eas­ier or to do some­thing you could not do be­fore; pro­grams are gen­er­ally hard enough to use as it is, and a pack­age be­ing un­main­tained al­most guar­an­tees that you will spend more time on it than an equiv­a­lent main­tained pack­age. There are usu­ally plenty of choic­es, so go use one of them.

A com­mit­ment to main­te­nance is also a use­ful thing. Take GNU Emacs, or the GNU com­mand line util­i­ties in gen­er­al. There are quite a few of them, they are com­plex and pow­er­ful, and take a while to learn. To profitably use them, you will need to in­vest time—I had learned enough about the Core­utils to use them com­fort­ably within a few months, and GNU Emacs took about half a year to re­ally learn to any sat­is­fac­tory de­gree. Other al­ter­na­tives like ‘nano’ would have taken less time to learn, but the GNU tools offered me more pow­er.

More im­por­tant­ly, the whole rea­son I was will­ing to spend so much time learn­ing Emacs was be­cause Emacs has a his­tory. It was be­gun in 1984 and has been in con­stant de­vel­op­ment in the more than 2 decades since. It is likely to con­tinue to be de­vel­oped for decades (if only by the ) by the same gnarled old hack­ers who wrote it orig­i­nal­ly.

Even bet­ter, it has the in­sti­tu­tional sup­port of be­ing the GNU Pro­jec­t’s offi­cial text ed­i­tor. In other words, learn­ing Emacs is in­deed a steep price to pay but that’s al­right since it is en­tirely plau­si­ble that you could be us­ing it for the rest of your com­put­ing life. Six months of not par­tic­u­larly pro­duc­tive text edit­ing may sound like a lot, but when set against 20 or 30 years of use, the pro­duc­tiv­ity gains seem worth­while.

Be­ing main­tained is just the most ba­sic cri­te­rion though, and many tools will meet that ba­sic lev­el. Un­main­tained projects tend to be for­got­ten, and you usu­ally won’t see them dis­cussed in lists of pro­jects, so in a sense you can just as­sume tools are main­tained. The sec­ond, more diffi­cult fea­ture is:

Extensible

  • It should be ex­ten­si­ble.

There are very few tools which you will want to use, now and forever, ex­actly the way they come. Even a com­mand as hum­ble as ‘cat’ nev­er­the­less has >9 op­tions! For some­thing as com­plex as a browser or text ed­i­tor, you will want to cus­tomize and most prob­a­bly ex­tend it. Rather than us­ing nasty hacks to get around this fact, just use a tool which can at least be script­ed.

  • How­ev­er, script­ing is­n’t al­ways the best way. Prob­a­bly the best way is the Emac­s-style pro­gram ar­chi­tec­ture1: a sim­ple, effi­cient, and per­for­mant core which sup­ports a panoply of ex­ten­sion­s—the sum of which is the ap­pli­ca­tion. If the bulk of the ap­pli­ca­tion is be­ing writ­ten as ex­ten­sions, you get nu­mer­ous ben­e­fits which in­clude:

    1. Mod­u­lar­i­ty; and the abil­ity to dis­able what­ever you do not need (with at­ten­dant ben­e­fits in per­for­mance, re­li­a­bil­i­ty, and se­cu­ri­ty)
    2. Ease of ex­ten­sion. Ob­vi­ous­ly, since the de­vel­op­ers would have striven to make the large body of code—which they will spend most of their time edit­ing—­clean and easy to change. If you have to do every­thing in Perl or Emacs Lisp, for ex­am­ple, you are ob­vi­ously go­ing to have nice li­braries and fea­tures to use. These fea­tures and li­braries will also be avail­able to you.
    3. Porta­bil­i­ty. The small core is all that needs to be port­ed, some­times. Porta­bil­ity is al­ways a good thing.
    4. Fea­tures. Emacs con­tains the prover­bial kitchen sink; Irssi has more ex­ten­sions and skins than I can count; and Fire­fox has pre­cisely 2.89 mil­lion ad­d-ons. If users can add fea­tures with­out wait­ing for the offi­cial de­vel­op­ers and re­lease cy­cles, they will. And odds are pretty good they may have al­ready done ex­actly what you need­ed, or solved a need you did­n’t even re­al­ize you had.

It’s lovely to be able to make use of other peo­ple’s ex­ten­sions in your shiny new toy, but do you know what to do with it now? Ob­vi­ous­ly:

Comprehensibility

  • You should be able to un­der­stand it.

This is a valu­able prop­erty for a num­ber of rea­sons al­so. An ex­am­ple I like to use is the XMonad tiled win­dow­ing man­ager for X. Be­fore, I had used Rat­poi­son and Stump­WM, but I was never re­ally sat­is­fied be­cause I did­n’t un­der­stand C or Com­mon Lisp so many things were and re­mained a mys­tery to me. This made ex­tend­ing them, de­bug­ging them, even just read­ing the doc­u­men­ta­tion to use them—it made them all more diffi­cult than they had to be.

With XMon­ad, I un­der­stand most of it. I see how the ex­ten­sions work, and have writ­ten my own. The im­per­fect mir­ror of the doc­u­men­ta­tion does not con­fuse, as I can eas­ily turn to the code which is the ul­ti­mate doc­u­men­ta­tion. This point ties into the first and sec­ond points. If you un­der­stand the code and the ar­chi­tec­ture, then you are in a much bet­ter po­si­tion to ex­tend it, and po­ten­tially main­tain it.

This goes back to the first point; you should never need to main­tain it, but given your in­vest­ment in it, you may want to and it’s bet­ter to be able to main­tain it to the de­gree you need it to func­tion—­some­times main­te­nance is just a mat­ter of up­dat­ing a few files or the pack­ag­ing sys­tem.

Popularity

  • Try to use stan­dard stuff.

For ex­am­ple, Bash is by all the for­mer cri­te­rion a good choice for one’s shell. It is main­tained by the GNU Pro­ject, it is cer­tainly ex­ten­si­ble and pow­er­ful, and it’s rel­a­tively un­der­stand­able. But the re­ally nice thing about Bash is how very stan­dard it is: every Linux dis­tri­b­u­tion in­cludes Bash, and even set it as the de­fault shell.

And if an op­er­at­ing sys­tem does­n’t run Bash as de­fault, it is ba­si­cally guar­an­teed that Bash will run on it (or there will at least be shells with Bash-com­pat­i­bil­i­ty). This is an ad­van­tage you should not un­der­es­ti­mate. Be­cause of this ubiq­ui­ty, there are pow­er­ful net­work effects op­er­at­ing in fa­vor of Bash guar­an­tee­ing that it will be use­ful for you for a very long time. Stan­dard means you will be able to get your hands on it, stan­dard means there will be doc­u­men­ta­tion and peo­ple work­ing to solve bugs and other peo­ple tak­ing ad­van­tage of the ex­ten­si­bil­i­ty, and so on. Stan­dard means that new im­ple­men­ta­tions and forks are that much eas­i­er. Stan­dard means many things, but from a user’s per­spec­tive, stan­dard is gen­er­ally a good thing for soft­ware and lan­guages to be.

The fi­nal ma­jor con­sid­er­a­tion was left to last. It should come as no sur­prise to mod­ern pro­gram­mer—s­in­fully awash amongst high­-level garbage-col­lected in­ter­preted lan­guages as they are—that the least im­por­tant fac­tor to con­sider is the level of:

Efficiency

  • effi­ciency of a pro­gram.

This is the fi­nal con­cern be­cause ap­pli­ca­tions spend lit­tle time do­ing in­effi­cient things. The ra­tio­nale here is that, per­haps Emacs may be some­what slower than a less ca­pa­ble or portable ed­i­tor—but you will not save so much time on quicker screen up­dates &etc. as to make up for real hours lost in port­ing the other ed­i­tor or work­ing around its lack of fea­tures (see ).

There are other con­cerns here: it is eas­ier to make an ex­ten­si­ble/pow­er­ful/­portable ed­i­tor more effi­cient in the bot­tle­necks than it is to hack in those fea­tures to an effi­cient ed­i­tor never in­tended for those fea­tures2. But if you are truly faced with two choic­es—each of whom seems equally solidly main­tained, ex­ten­si­ble, stan­dard, etc.—then go with the more effi­cient one. After all, effi­ciency is a virtue and does make the ex­pe­ri­ence more pleas­ant and gives you the op­tion of us­ing it on slower com­put­ers.

Alas, just mark­ing down these fea­tures does­n’t solve every prob­lem. For ex­am­ple, choos­ing be­tween Vim and Emacs was easy for me—Vim’s sup­posed effi­ciency did­n’t (in my reck­on­ing) out­weigh the in­creased stan­dard­ness and com­pre­hen­si­bil­ity of Emacs. Or take Bash com­pared with Zsh. Bash is clearly more stan­dard and is clearly bet­ter main­tained, be­ing even older than Zsh and the offi­cial shell of the GNU Pro­ject, and it is prob­a­bly mar­gin­ally more effi­cient. But I nev­er­the­less chose to switch to Zsh.

Why? I just liked it bet­ter. It has more fea­tures, yes (but not sig­nifi­cantly more); it has Bash com­pat­i­bil­ity (sure, but not as good as the real thing); it makes my con­fig­u­ra­tion files cleaner and eas­ier to main­tain, sure (but they were diffi­cult to con­vert, and are now no longer quite so portable). Ba­si­cally every point ad­um­brated ar­gues strongly for Bash and at best, weakly for Zsh. But I liked it bet­ter, and in the end that mat­ters.

Short configurations

What other things should we keep in mind? Well, as time pass­es, I’ve found con­fig­u­ra­tion files tend to grow. A good thing to do when a con­fig­u­ra­tion file has grown par­tic­u­larly elab­o­rate is to sim­plify it.

Slim it down, re­move every­thing you haven’t needed in the last sev­eral months. If you still have a huge file, see whether a large chunk of it makes sense to split out.

For ex­am­ple, for the Zsh I have: ~/.zshenv, for en­vi­ron­men­tal vari­ables and shell set­tings that all Zsh in­vo­ca­tions need; ~/.zaliases, hand-writ­ten aliases and func­tions; ~/.ztypos, con­tain­ing all aliases au­to­mat­i­cally writ­ten to cor­rect ty­po­graph­i­cal er­rors I have made in the past; ~/.zlogout and ~/.zprofile, for lo­gout/lo­gin stuff; and fi­nal­ly, ~/.zshrc, which con­tains every­thing needed for pleas­ant in­ter­ac­tive use. Clearly it’d be ab­surd and ex­tremely awk­ward to stuff all of that into a sin­gle file, as well as po­ten­tially slow.

But sup­pose you have re­moved cruft, writ­ten stuff as well and con­cisely as you could, and split files out, and you still have too much? Now it comes time to give back to the free soft­ware com­mu­ni­ty. Con­sider care­fully your set­tings: per­haps they are very com­mon and you could file a bug sug­gest­ing they be made the de­fault? That would then be a line you could re­move. Or per­haps you have on your hands a de facto use­ful ex­ten­sion to the pro­gram you could pack­age up and offer on­line some­where, or even offer to the de­vel­op­ers as some­thing to add to all the other ex­ten­sions in­cluded by de­fault.

Take one, leave one

There is one last piece of ad­vice:

  • For every new tree plant­ed, let one be up­root­ed.

This is a good rule to fol­low with all pos­ses­sions. If you buy a new pair of shoes, give away or junk the old pair which you no longer need or can use. If you pur­chase a new book, sell or do­nate that old one you will never read again. If you add one pro­gram to your sys­tem, try to re­move an­oth­er—per­haps one you never used, or per­haps one made re­dun­dant by the new one. If you in­stall ELinks, re­move Lynx.

Re­dun­dancy wastes re­sources, it im­poses men­tal bur­dens, it in­creases in­er­tia and re­sis­tance to change. The more stuff you have that you do not need, the stu­pider your pos­ses­sions get. If you have a room burst­ing at the gills: you can­not freely trav­el. You can­not eas­ily change your place of res­i­dence. You are no longer sure what do you and do not have, you are in­creas­ingly men­tally stressed. You lit­er­ally can no longer freely move about. In ex­treme cas­es, peo­ple have been known to die be­cause they re­fused to let go of things3.

Try to keep mat­ters el­e­gant and un­clut­tered. There is a differ­ence be­tween el­e­gance and com­pe­tence—and this differ­ence makes all the differ­ence in the world.


  1. For my pur­pos­es, the many vari­ants such as the XMonad model are im­ma­te­r­i­al. Yes, it is a very in­ter­est­ing model (the pro­gram com­piles a fresh bi­nary with the user’s new con­fig hard­wired in, se­ri­al­izes out the cur­rent global state, and restarts it­self with the new bi­nary and passes it the se­ri­al­ized state)—but the de­tails of how the ex­ten­si­bil­ity is ac­com­plished are only im­por­tant if the method is crappy and un­re­li­able.↩︎

  2. As a big­oted Emacs user, I of course see Vim as the clas­sic ex­am­ple of at­tempt­ing to shoe­horn in a fea­ture like a first-class ex­ten­sion lan­guage—with hu­mor­ous re­sults!↩︎

  3. Often due to men­tal dis­ease; see ↩︎