The Future of Emacs

A confession: I have always been a VI man.
A further confession: I have never been a very good one.

The very thing that alienated me from Emacs is perhaps its greatest strength: its boundless flexibility.  Emacs is designed in such a way that a feature can be added without a substantial architectural learning curve.  Despite the sheer breadth of functionality the program has grown to encompass, at base, it is a relatively simple program: it is a text-editor with plug-in support.

So why VI over Emacs?  And will either of these programs be around in 50 years?

When I was originally learning VI, I recognized it as a dated technology.  It's a fantastic tool for working in a terminal, but is outshined by a host of editors in a modern, windowed environment.  I chose VI over Emacs because I wanted to be able to work in terminals, not because I wanted to learn a sophisticated IDE; simply put, VI is basically the same on any *nix machine, Emacs isn't.  VI is a skill that doesn't vary machine-to-machine.  Emacs keywords and features vary by release.

VI is useful but losing purpose with time.  In the long run, will Emacs' flexibility save it from irrelevancy?  To answer these questions, I shot off to 2059, explored the Emacs dev-sphere and had a quick holo-con with 70-year-old project maintainer Jerry "Wildebeest" Gorman.

Kurt: I have to say, it's stunning to see how long the Emacs project has lasted.  Could you describe some of the changes to the system in the last 50 years?
Gorman: Oh, it's been incredibly active.  We've optimized our algorithms for quantum architecture, we've integrated ASCII-video translation features so video streams can be rendered as stacked layers of colored ASCII text, we've worked on enhanced session concurrency, so a hundred users can share thousands of frames efficiently, we've--
Kurt: Are any of these developments unique to Emacs though?
Gorman: What do you mean?
Kurt: I mean, can Emacs do anything that other IDEs aren't doing right now?
Gorman: Well, it's written in Lisp, which is--
Kurt: So?
Gorman: And it's free as in speech.
Kurt: Plenty of other things are as well.
Gorman: And it has a small memory footprint.
Kurt: Don't you have petabyte QRAM chips now?
Gorman: And it--
Kurt: Can't you just admit that this is all nostalgia and outdated skills?
Gorman: No, it's totally about--
Kurt: What!?  Do you still check your e-mail with Pine too?
Gorman: Yeah, what about it?
Kurt: Gah!

To all readers curious as to the future of Emacs, I apologize for hosting such an embarrassing interview.  I just often feel like developers deny the real reasons for their habits.  Anyway, Emacs does offer some valuable lessons to modern developers, even if the platform itself is old:

1. Keeping the system open and easily flexible can grant it a long, rich life: A program need not be open-source to maintain an active development community, but should grant developers access to anything they could want to change.  Winamp is an outstanding example of a closed-source program that maintained a very active development community.  It gave users the ability to modify its appearance, its inputs, outputs, and to create new windows and features.  The end result was a product that was heavily used for years.  Though Winamp offers a cautionary lesson: by remaining closed source, you increase the chances of a product dying a slow death, since its longevity (and legal ownership) depend on the whims of someone other than the developer--in Winamp's case, AOL.
2. Simple interfaces can encourage complex development: Keeping the bar to entry low can keep people interested.  Emacs was easy to add-on to, and so many people learned to add to it.  This can either be done by defining well-structured, simple interfaces, or (more dangerously) by keeping most of the program's data flatly structured.  Firefox takes something of a hybrid approach, defining interfaces for various layout information, but keeping the data itself (including settings and page trees) "flat" and global.
3. Maintain a good way to publicize user's contributions: In the case of Emacs, maintained packages are kept in the program itself.  Because these features are most often accessible by keystroke combinations, they don't cloud up screen space and because Emacs is a terminal program, they're not very large.  Many modern projects maintain web pages dedicated to their add-ons.  Winamp and the Mozilla projects are particularly good about this.  Eclipse offers a well-centralized update utility, but lacks a good central resource.  Consequently, fewer minor changes get published, which potentially are slowing down the growth of the platform.  There are many outstanding, large contributions, but minor 3rd party enhancements are rare in the Eclipse ecosystem.

Emacs is something of a legend, and it can sometimes be hard to separate the program from GNU philosophy from Stallman's ego.  And in truth, maybe they shouldn't be completely separated: each has arguably benefited from the other.  Emacs may technically live forever, but I consider the program increasingly irrelevant.  Its lessons, however, can still be applied.  And I have yet to see another development tool grow  in such a broadly communal fashion.