On Skill vs Automation in Code Editing -------------------------------------- date: 2022-11-20 22:52:35 EST I've been playing with my text editor setup between jobs, first dabbling in Emacs (see my last post) and now finally taking the time to replace my linter-heavy ALE config (Vim) with NeoVim's native LSP support. And well, the LSP mode kind-of blew me away. It truly felt like IDE features in NeoVim. And this got me thinking about whether NeoVim, Emacs, and VSCode are really "Text Editors" and the line between skill based editing and assistance via tooling. Let's start at one extreme: GitHub CoPilot being able to write code for you. There's obviously knowledge needed to verify and tweak it, but as far as skill-based efficiencies, this feels pretty easy to pick up. Pay Microsoft the fee and the efficiency is yours, little learning investment required. I think vi (not Vim) represents the other extreme-- being efficient in vi is 100% based on memorizing an arcane language. I'd argue that vi(1) is a skill-based efficiency. Now I'm not saying it's a skill worth learning (per-se), or even a skill that's hard to learn (I don't want to come across as looking superior for memorizing it), but arguably it's a skill. More efficient editing comes down to learning the language better. There is an interesting medium here between AI writing code and learning an editor that uses the least number of keystrokes to make a change, and I think LSP is that medium: it provides the operator with smart operations (like renaming) based on understanding of the code structure. I've only begun to scratch the surface of LSP, but even just watching the rename function work was eye opening. As an illustration, let's look at how I'd change all instances of `foo` to `bar` with `:LspRename` mapped to `gr`. With LSP: `grbar` Without: * If only a few: `*ciwbar<ESC>n.n.n.n.` (select the next one, then change it to bar, then next -> change -> next..) * If many: `:%s/\<foo\>/bar/gc` (y/n at each prompt) There's a clear slowdown with Vim (beyond the amount of typing): the mental overhead of having to decide if each is a false positive or not. It can be eliminated a bit by the word-boundary \<\> and the search for just \<foo\> via *, but it's definitely not perfect. With LSP, the server knows the instances and can tell the client every location without the operator changing anything. The major downside of LSP AFAICT is that it's limited to languages that have a server (and code in general). In a CSV file, for instance, `gr` just won't be an option. And of course, for massive codebases it can be very expensive to run / slow. If anything, this just reinforces the difference between a _text_ editor and a _code_ editor, and I expect we'll continue to see the gap widen over time (with the line between IDE and code editor maybe blurring a bit). vi is a text editor through and through. Vim, Emacs, and VSCode are all code editors (the former two if configured properly). In a world with CoPilot, I wonder how far Code editors will go. And I wonder if that'll make it harder for new languages to form (with such a barrier for tooling, etc). If developers become operators of AI, there's a real chicken and egg problem with new languages: the AI just won't have any samples to learn from if humans don't write it. I'd like to think the AI-operator-coding world is far away (but admittedly I've never tried CoPilot myself, so I don't know how usable it is). What I do feel pretty strongly about is that it puts oneself at a disadvantage to use a pure text editor for professional coding where a code editor might provide a more full-featured suite of tools. Even the most adept vi(1) user probably can't keep up with an LSP enabled editor. But hey, I'd love to be proved wrong. As someone who strives for simplicity in software (this is on Gopher after all), I'd love to believe some combination of vi(1) for surgical edits, sed(1) for bulk edits, etc could culminate to VSCode efficiency. It just feels like a losing battle having a human make all the incantations when we've written language parsers that can make high level edits for us. Now, the more philosophical question is: with the trend towards better automation, is it worth becoming a skilled/efficient editor of text at all? How much of our time is thinking, designing, and generally not cranking out words? Is it worth hours of learning, config customization, to get the most efficient environment? At what point is one doing themselves a disservice by refusing to use a code editor and insisting on editing code as text? I'd like to believe (maybe partially biased by sunk cost fallacy) that efficiently editing text is still an important skill, even with better editing software: so much of the things we deal with are unstructured text (logs, emails, blog posts, data files, etc). Of course, you can't always use your favorite editor for all text (unless that editor is Emacs and you're willing to customize it :)). I also think there's some joy in knowing a language well enough to code in it without assistance (even if that's probably not the way one should write professional software while "on the clock"); its like a chef cooking from memory instead of following a recipe: probably error prone and slower, but enjoyable? There's a better analogy out there somewhere.