Tuesday, February 24, 2009

emacs and vi

There is an age-old debate (er, war) between Unix people who use vi and those who use emacs. I use them both daily, so it's a debate I understand. I can see both sides to this one.

I think I got a glimmer of insight into the debate this morning, and thought I'd share it. Emacs and vi represent very different software philosophies: vi is from the Unix school of thought, emacs is from the Lisp school.

The Unix school of thought is generally described by the pithy saying "Do one thing and do it well." Each utility or application on a Unix system is small and very limited in its scope. The power of Unix comes from combining and mixing these utilities to create larger single-use "applications". I am convinced that the two "commands" that most characterize Unix are ``|'' and ``tee.''

Vi is a prime example of this philosophy: it is probably the best text editor for console-based file manipulation. With a powerful regular expression engine, a script API, and a wide variety of concise commands, I am convinced vi is the best way to create or alter files on the disk. It does one thing very well.

Lisp software is different. Instead of the proverbial one thing done well, Lisp software is open-ended. It's viewed as perpetually incomplete: it can always be expanded on; it frequently involves some sort of interactive prompt at which the software itself can be changed by the end user; and meddling with it is generally expected, if not encouraged.

Emacs is Lisp software, and it shows: it's the open-ended text editor, if it can really be called a "text editor" at all. In emacs, I can write some emacs-lisp expressions in a buffer and evaluate them on the fly. Those expressions can do anything from some simple calculations to altering the behaviour of emacs itself. When several of those expressions are used together, they can be packaged as an application: an application that runs atop emacs.

For system administration work, I reach for vi. Between ubiquity (vi is on every system) and sed-compatible regular expressions, vi fits perfectly into the Unix administrator's toolkit and mode of thought.

And as a side note, let me point out that if you don't know sed and awk, you're not a complete Unix administrator. These tools are essential, and you need to learn them. Perl is great, and you need to know Perl too, but sed and awk are indispensible to Unix administration.

When I write code, I always reach for emacs. Emacs is the perfect coder's editor. Let's be honest, emacs is more IDE than editor. Emacs allows me to see my code clearly highlighted, it has sensible (and adjustable) code formatting rules, and it lets me write and run the code all in one place. I get a kick out of the discussions on Perl Monks about code formatting: I always just use emacs and let it format the code as it sees fit. It always does a good job.

And as I've been using more and more Lisp to solve my data problems, I've found emacs + SLIME + SBCL to be the only way to code.

No comments: