Wouldn’t this mean that editors which have a more “mechanical” means of getting information (like a keyboard shortcut) fare better than ones with a complicated graphical display, as the cognitive load is reduced? In this case, Emacs or Vim might be better than VS Code, despite the learning curve.
I fear a bit of confirmation bias on this one, so correct me if I’m wrong.
We need to tease out several different things here. In my opinion:
- Information density is good. If you can stuff more data on screen, by using annotations, underlines, fringe markers, whatnot - it's usually a win. As long as the indicators don't interfere with each other, human brain can quickly learn to filter them with near-zero effort.
- Clicking is bad ergonomics. It has high enough overhead compared to keyboard that it's enough to interfere with focus and the state of flow.
- Most animations are bad ergonomics. This, ironically, applies to the author's CodeRibbon[0]. It looks like a great idea. Then you think how to implement it in Vim/Emacs, with less animations. Then you realize that you can get this with some tweaks to how you switch buffer/window configurations, and it'll give you same benefits with better ergonomics.
- The article underexplores the third choice of the predator - enriching the environment. Or, perhaps, we should introduce a fourth choice[1]: meta-enrichment, or developing technology. That is, reconfiguring and extending your tooling to offer you more/different contextual cues (foraging), navigation tools (navigation) and operations (enrichment). This is where Emacs shines above all - for a proficient Emacs user, meta-enrichment is something one just does. Of course, as a developer living in Emacs, I suffer from confirmation bias[2] :).
[1] - Incidentally, one that distinguishes humans from the rest of life on Earth.
[2] - I mean, over the past year I spent about a week worth of time on developing what now is 1400 lines of Emacs Lisp[3] implementing some creature comforts, including a "control panel" for a particular flavor of development I'm doing. I could've avoided spending that week if I used VS Code instead, but then I'd also lose on all the benefits I get from a tool that fits like a glove.
[3] - That's 1400 lines of my own Elisp, on top of the ton of third-party elisp packages and customizations specific to them.
The cognitive load would come from unfamiliarity more than anything. It dissipates once you learn and use the system enough regardless of how you interact with it(assuming the UI is consistent and reliable, which far too many aren't)
I've been using the same IDE for the last 10 years because that is what my colleagues use. Over the last decade the UI has changed significantly. Not only that, the keyboard shortcuts also change, and often don't work the same across different IDEs in the suite. For example, the shortcut to vertically select a column of text has changed at least twice. I like Jetbrains, but considering switching to something simpler that changes less often. Might miss out on some advanced features, but I don't use those often, and maybe I don't need it anyway
vi/vim/neovim has a very consistent interface. It does have a learning curve but it is very pleasant to use once you've learned it. A bonus is that you can now edit text on pretty much any machine without installing anything, desktop or server.
I moved from the Jetbrains stack to vim ~3 years ago and haven't looked back. Mastering vim of course takes some time, but getting up and running and being productive does not take too long at all.
It did help that I was mainly writing Go at the time which has the great vim-go plugin. Not sure how I would have done if I was writing mainly writing another language (C#, Java etc come to mind as perhaps benefiting more from a full-fledged IDE).
I just use the vim plugin in Jetbrains products. I get vim navigation, editing modes, basic macros. Vim emulation is not thorough, so I can’t get more complex features, but they seem unnecessary when I get Jetbrains features.
That's outside of my bag o' tricks. There was definitely some pain getting things to work to satisfaction in the Jetbrains tools. In a few cases I simply had to adopt a different workflow. But I'm feeling pretty happy about it now.
I can't say I understand the formula in the article, but I have interacted with emacs/vim and VS Code to some degree. I've also use several other IDEAS (Eclipse, NetBeans, IntelliJ, etc) and I have to say except for special circumstances (Java or C# like languages), the fact that I can easily navigate code via the keyboard and have multiple onscreen views into multiple files pushed the older editors far to the head of the pack for me. Unless there's some other compelling reason to use an IDE I very quickly dismiss an editing tool in favor of vim these days because of that multi-window/ view aspect. I don't need most of the other things wasting real-estate on screen and hate having to bounce back and forth between files if I can see the parts I need at the same time. It just flows better. If a tool can't give me at least a 2x2 grid of views into source files, I'll probably drop it without looking much further ...
IME more "mechanical" means definitely promote code familiarity. For some languages I use vim as my primary editor -- generally anything frontend. OTOH, at least for me, I'm definitely a lot slower with pure vim when working with java. I use intellij for that. However, i use IdeaVim to get the vim key bindings, so 80% of the time I'm actually still using my IDE very similarly to how I use vim, so I think your point regarding "mechanical" means still holds. My biggest complaint is mainly that I wish I could access more of my IDE's features with just vim key bindings.
Sometimes when I'm really and truly stuck, I will open up a java file in vim. In those situations, the forced slow-down is actually an advantage, and I get a much deeper understanding of what I'm looking at. I can't code well this way (perhaps that's on me), but it can be a powerful aid in debugging at times.
I fear a bit of confirmation bias on this one, so correct me if I’m wrong.