[TUHS] End of an era: the last ATC (USENIX Annual Technical Conference)

[r.stricklin]

> On Jul 18, 2025, at 12:43 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> Modern tools are more
> complicated because they do more stuff.  Taking your position to the extreme
> would have you using a pipeline piped to ed, would it not?

preface: none of this is to contradict your position. I was a little confused about the implications of your apparently contradictory statements, that if someone worked for you you’d force them to use vim, but also that people should be free to use what they like, but I don’t feel like I’m owed an explanation for it, so that isn’t why I’m replying.

I never bothered to develop a complicated .exrc and I don’t do much of my programming in vi-like editors, so for the most part I’m not super invested in the feature differences between vi, nvi, vim, etc. I do prefer vi-alikes to other unix editors, but I can cope with ed when I need to. I probably wouldn’t choose to use Emacs unless I had no other choice, but I easily understand why some people do. The vast majority of my editor use is for systems-type tasks, so I don’t imagine it’s difficult to understand why I got here. When I do use vi for programming, it’s primarily to update existing code, but I could reasonably live with vi alone, if that was all I had.

I am often surprised at my professional colleagues who insist they need vim in particular, and complain loudly when a vi-like editor that isn’t vim is all that is available. Almost without fail, these are the same guys I see get thrown when their terminal emulator isn’t letting them use the arrow keys to position the cursor, who only ever move the cursor around one row or column at a time, who only ever i or o, never I or O or A or c or C or $ or 10G or u or w or y or anything, who don’t know how to use any of the ex commands, read text in from files or commands, or use any number of other features more advanced than what you got in Windows notepad, and who insist, for some reason, that they need vim to “copy and paste”. Their incuriousness really serves to give me a reflexive (and as this thread reveals, admittedly sometimes also unfair) disdain toward someone who claims to “need” vim.

That’s just an opinon, though, and as such, it’s worth a half pitcher of spit. I try not to get too hung up about it. Everybody needs a hobby. If it’s pounding ‘k’ and ‘l’ a hundred and seventy times in a row, then… boogie on down.

Anyway. So it also turns out there are other reasons to prefer classic vi. One of the larger software projects I maintain (mostly using bbedit) is a network booted embedded linux system which hosts a ruby-based configuration management system, for doing standalone policy based configuration control of datacenter hardware resources (e.g. RAID configuration, firmware versions, BIOS settings, defect detection and reporting, etc.) It’s a relatively complex system solving a relatively complex problem, and the complex problem is what I want to stay focused on. So that makes limiting the number of external dependencies an important consideration for the project. Every external dependency becomes something that has to be downloaded at runtime, something that takes space in the ramdisk, and a set of binary artifacts that have to be tracked, integrated, and their lifecycle managed. 

It’s also important to be able to use the embedded linux system to investigate defects in the configuration management system, when they crop up, and although we get nano “for free” as a byproduct of having based the nucleus of the system around the Debian installer, there are a long list of reasons why nano is too obnoxious to live with. It was worth adding a vi-based editor to the system for such occasions. But the standard ‘vim’ has a relatively long list of external dependencies that we would be forced to carry along with it, and subsequently, to maintain in perpetuity. Even ‘vim-tiny’ and ‘nvi’ had longer lists of dependencies than I was happy with. I ended up adding ‘elvis-tiny’ to it, which is pretty much entirely self-contained. Entirely adequate for purpose, perfect on maintainability requirements. 

This is part of the calculus when folks say they find the feature bloat distasteful. It isn’t always about end-user experience (though sometimes… what the heck is going on with Jira these days?!? don’t answer that.)

Which reminds me, tangentially: I often get tripped up by “helpful” vim features (I can’t tell you how many times I have accidentally opened an unwanted Help panel), but I categorize those as minor annoyances that I try not to get too hung up on. This time, though, I was using 'vim' on a remote system in an xterm, and wanted to copy and paste something into a different window. ‘vim’ took all the mouse events for itself and it wasn’t obvious (in the moment) how to make it stop. I can’t think of a time I ever wanted to use a mouse to directly control a vi session. That one made me rage a bit, although it was simple enough to fix (TERM=vt220, try again). I got over it.

Obviously there is an entirely different set of tradeoffs if you’re installing an editor on a programmer’s workstation. But I wanted to be very concrete about why I don’t favor the idea that “vim is a 100% replacement for vi in every possible circumstance”. At least by the Debian maintainer standards, nvi depends on Berkeley DB. vim depends on SELinux, libacl, libsodium, gpm, and others. Why? (…he asked, rhetorically)


ok
bear.