Occasionally someone will stop by my office to look at some code I’m working on and I’ll pull it up in Emacs.  Within a few seconds most people ask what editor I’m using and why.  After all, it is 2009; surely there exists something better than a 30 year old editor that uses a variant of Lisp as an extension language?  Well, I’ve looked and if a better editor exists, I haven’t found it yet.

Language Support

I’ve been using Emacs as my primary editor for the seven years.  I’ve written C++, Perl, Python, Scheme, Common Lisp, XML, and Latex in Emacs; each of which was syntax highlighted and indented appropriately.  Emacs has allowed me to become proficient at a single editor while still assisting me with all of my text editing tasks.

Source Code Control Support

Over the years I’ve had to edit code that has been stored in Perforce, Subversion, git and CVS.  Emacs has support for all of these source code control systems.  For most day to day editing tasks involving check in/out and adding/removing files I don’t even need to leave Emacs.

Smart Search and Replace

Emacs has the best search and replace of any editor that I’ve used.  It searches and replaces using case “smartly”.  In just about every case it does exactly what I intended for it to do by default.

For example replacing “foo” with “bar” in the string “Foo foo FOO”  results in “Bar bar BAR”.  Each “foo” string was was replaced with a “bar” string that was capitalized to match.  If I had replaced “Foo” with “bar”, the string would have become “bar foo FOO” instead; only replacing strings that matched the case exactly.

Ediff

Ediff is a standard Emacs package that is perfect for cleaning up code before committing.  It allows you to perform a diff between two buffers (one buffer being the current version in the source code repository if you’re using git, SVN, CVS, or Perforce) and highlights the changes.  The key to ediff though is that it allows you to use the “A” and “B” keys to yank changes back and forth between the two buffers. Typically I use this to remove any new line insertions and hunks of debug code that I’ve added before committing.

TRAMP

TRAMP (Transparent Remote Access, Multiple Protocols) is an Emacs package that allows you to edit files on remote systems as if they existed on your local machine.  The only difference is a slight delay when reading/saving the file as it has to be done through the connection to the remote machine, which is obviously not as fast as reading/writing to a local disk.

While I typically use FUSE to mount remote directories through SSH, this is only a solution in Linux.  TRAMP allows Windows users to edit files on any remote machine that they can FTP or SSH into.

Community

The Emacs community is active and helpful.  One of the most useful sites is the Emacs Wiki.  Here users post tips, questions and answers, along with helpful bits of elisp that they’ve written.  If I want to do something new with Emacs, the Wiki is usually the first place I look.  If you’re thinking about trying Emacs, you could do much worse then checking out the Emacs Newbie section on the wiki.

It’s not often that I run across a new tool that I immediately start using dozens of times a day and installing on every machine I login to. ack is one of those tools.

According to the ack website, “ack is a tool like grep, aimed at programmers with large trees of heterogeneous source code”. The description is not quite accurate, for even if all of your source is in the same language and you don’t have much of it, ack is incredibly useful. ack is designed to reduce the amount of time spent searching through source trees.

By default ack searches recursively through subdirectories of it’s current working directory for occurrences of a pattern. It also ignores files used internally by the likes of darcs, git, Mercurial, Subversion limiting false positives. These two features alone make it worth using. Add in the colorized output by default and ack is indispensable.

ack Screenshot

ack is available at the appropriately named betterthangrep.com.

Mythical Man Month

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) was original published in 1975 and portions of the book are certainly that dated.   In one chapter Brooks gives as an example of “over-design”:

For example, OS/360 devotes 26 bytes of the permanently resident date turn over routine to the proper handling of December 31 on leap years (when it is Day 366). That might have been left to the operator.

Typical end users today would probably find the idea of manually updating computer clocks to deal with leap year appropriately rather annoying.

Throughout the book, though the examples are dated, the information that Brooks presents is timeless.  One point that really hit home was Brooks’ ideas about the optimism of programmers and their assumption that “each task will take only as long as it ‘ought’ to take”.  A great recent example of this has been the talk on YCombinator regarding writing stackoverflow in a weekend.   Programmers see problems in code, and in my case, code that looks fun to write.  All of the boring validation and end-user junk doesn’t even come to mind when I think about a new project.  So while I’m thinking and estimating the time required to code a solution that splits a piece of the problem up into chunks so I can run it across multiple cores…the time required to make the UI friendly just slipped my mind.

One of the primary themes from MMM is commonly known as Brooks’s Law:

Adding manpower to a late software project makes it later.

Brooks explains the reasoning behind his law; much of which is due to the fact that certain tasks are sequential and must be completed in order, while other tasks require communication between the people working on that task.  It’s also in MMM that Brooks cites the famous example that “The bearing of a child takes nine months, no matter how many women are assigned.”

For me, the book starts strong but then tapers off.   Overall it’s a good read with plenty of useful information to get you thinking.

Follow

Get every new post delivered to your Inbox.