The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy

Overleaf allows you to work with several authors at the same time on the document. I was skeptical (after all, git allows that too). But after using that feature, well, it is just the killer thing. Now Overleaf doesn't add much on top on my own Latex installation. But the collaborative thing is just spot on (much like Google docs which I have discovered not a long time ago; same analysis : not that good presentation tool, but working together is just incredibly useful).

If you're not a professional web developer, spending 80 hours learning how to modify Emacs will give you much more control over Emacs than the control you get from spending 80 hours learning how to modify VSCode.

Or ar least that was my experience though I was in my prime when I learned Emacs decades ago and almost 60 years old when I spent the 80 hours learning how to modify VSCode.

(I feel I have barely scratched the surface of VSCode and of web tech.)

Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

One more thing. For years I went without internet access in my home, yet during those years I continued my habit of doing my emacs modifying at home: all I needed to do was make sure I had the Emacs Lisp reference manual and the Emacs Lisp source-code package installed. On every Linux distro I have used, these are standard packages, and they are all the information I needed to make most of the modifications I made to my local Emacs environment. In contrast, although there are troves of documentation on web tech, I have never succeeded in making a usable offline local copy of any of these troves, and wouldn't consider trying to modify (or explore the internals of) VSCode without constant access to the net.

Using non-standard notation for describing keyboard shorcuts doesn't help.

I can definitely sympathize with this. Typing in things has never been the bottleneck. Rather, deciding what needs to be typed in takes up the majority of the time. It probably helps that neither of my main two languages (Ruby for work/Haskell for fun) is all that verbose.

The passage that stands out most to me is this:

[W]hatever I've learned for technologies like Emacs, LaTeX, GNU/Linux, and so forth in the nineties, is still valid and useful to me nowadays. This can not be stressed enough: instead of un-learning and re-learning, I was able to improve and learn new things. This scales much better than any proprietary or temporary knowledge.

Even though I don't use emacs,[1] the point here is one that I've long realised and was instrumental when I was looking at potential directions to go with technology in the early 1990s.

I'd had experience across a number of computer systems, small and large, and all but Unix were proprietary. I'd already seen hard-won knowledge expired, often in a few years, as platforms or tools were eclipsed. And Unix was more fun...

Learning vi on the uni shared-access Unix server in the 1980s was a few weeks of pain and confusion. It's paid off handsomly over the subsequent 35+ years, as did basic fluency in the shell and its tools. Over time I've added to my toolset. Very occasionally old tools are replaced entirely, though quite often replacements themselves seek to retain interface (commands, keystrokes) compatibility.

I've also spent time (and occasionally money) learning proprietary systems ... virtually all of which are not entirely dead to me. Some still exist in small niches, others have all but disappeared.

In Future Shock, Alvin Toffler argues that in the future (that is, now), success will be determined not by those who can learn, but by those who can successfully unlearn old patterns. The older I get, the less likely this seems to be true. Unlearning is vastly more difficult than learning. Far better to get on a technological track in which basic principles, tools, and interfaces are adopted and retained as long as practicably possible, in a modular fashion. This avoids requiring wholesale skills obsolescence, provides for maximal skills retention and accretion, and where unlearning is absolutely required, tends to localise it to specific areas.

Voit's essay touches on several useful concepts directly or by reference (learning, unlearning, knowledge capital). I'd like to add another: the Lindy Effect. That's the tendency of things which have existed for a long time to continue existing. In technology it seems to be largely true. In particular, long-lived free and open tools seem to be good bets for continued relevance.

________________________________

Notes:

1. I did pick it up at one point and used it with some facility for a number of months. This was at a time that having ones own Unix or Linux server was still quite a novelty, and my manager at the next gig was an idiot who didn't believe in installing any software which wasn't shipped by the vendor. Life lesson: don't work for idiots, or let them dictate your opportunities.