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.
