The other side of the moon

Someone on quora asked why people still use editors like emacs and vim when more modern alternatives exist.

There were so many great answers that I didn't need to answer the original question. I couldn't possibly add more to the question of why emacs or vim. Instead, I was reminded of an experience where even emacs/vim weren't options.

Sometime in the mid to late '90s, I visited my sister at university. She was in a biology lab, and they had a single 80386 PC with DOS and Windows 3.1. The computer wouldn't start Windows and they didn't know why and they asked me if I could do anything.

Since I love debugging obscure problems like this, I decided to take a look. It turned out to be a simple case of there not being enough available RAM to start Windows. The box did however have 4MB of RAM, which should have been more than enough to start Windows... except, this was a 386, and for compatibility with older 8 bit software, RAM was split into Conventional memory (640KB), System ROM (640K-1M) and Extended memory (everything above 1MB), and this box wasn't configured to use extended memory (if you remember HIMEM.SYS).

To make matters worse, AUTOEXEC.BAT loaded a bunch of programs at startup that used up a bunch of RAM, which meant that I couldn't even start the basic EDIT program to edit AUTOEXEC.BAT or CONFIG.SYS.

My only option at that point was to fall back to the absolute basics.

COPY CON AUTOEXEC.BAT
COPY CON CONFIG.SYS

The equivalent on unix would be cat. COPY CON on MS-DOS stands for COPY what's on the CONSOLE (the keyboard in this case) to the destination file, overwriting it if it exists.

(See What is copy con? for details)

And I had to be really careful with what I typed because typing in the wrong thing would mean the system might not start up, and I didn't have a boot disk on me (remember I was just visiting with no plan of actually fixing a computer), and if I did have a boot disk, none of this would have been necessary.

Anyway, I managed to build a very basic AUTOEXEC.BAT and CONFIG.SYS from memory (though I cannot remember now what I put into them), which allowed me to reboot the machine with enough RAM to start EDIT which allowed me to further edit the files to reboot with enough RAM to start Windows.

What I learnt from this is that no matter how good a system you may have access to, you need to be prepared to use the absolute minimum available tools. On DOS this was COPY CON. On unix over a slow or lossy network, you might actually have to edit a file by sending single lines of sed. In order to be prepared to do this, you need to do this a lot. It turns out that vim and emacs are really just one step above sed (well technically one step above ed which is half a step above sed) although they are extendable to have all the features of Eclipse or Visual Studio if you like, but even without those extensions, they are far more powerful.

Even while working with Eclipse, I'll find that there are times when I need to quit Eclipse, open my files in Vim, run a few commands to do things that would take me ages to do in Eclipse and then return to Eclipse. I need to use Eclipse because that's what our dev team has standardized on, and it makes it easier when screen sharing with other devs.

If you liked this post, there's a far more fun video of how the JPL team debugged and fixed an issue 15 billion miles away on Voyager 1.