Live data from Hacker News

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

karl-voit.at

31–40 of 267 posts

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

#31
post #18

So, that's NOT the sunk cost fallacy. If you are still getting benefit from the cost, it's not sunk*. This is just not wanting to invest time into a new system while you're still productive in the current system. A sunk cost would be like, "Well, I spent $100 on this steak, so I'm going to finish it, even though the next bite may make me vomit." In that case, you paid for the steak, it cannot be returned half eaten,…

A cost is a "sunk cost" when it's already been spent and can't be recovered. The time invested into learning and configuring emacs is a sunk cost.

The fallacy is in persisting with it when other tools may be better, choosing to persist because of the time invested. Continuing with emacs because of that time investment even when there are better tools (for some part of the work at least) is an example of the sunk cost fallacy. Now, that doesn't mean that the tradeoffs can't be considered where someone determines that emacs is better to continue with for them in their particular situation (regardless of the sunk cost of time spent on it).

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

#32
post #2

I'm in a similar boat as in the first quote: Have used emacs for decades, glad that I do, can't imagine switching... don't think I would recommend it to anyone new, unless they are really open about learning something entirely different. Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. This s…

Why redo something if it works? People are still using Fortran because it works well for certain applications. Just because its old doesn't mean its outdated. I could even argue that since Emacs hasn't been phased out (and still has a decent user base) that it does something that other text editors don't (or can't) do.

Part of my point was that it's difficult to get into (still worth it overall), but another part is definitely that technology has moved on, and emacs often reminds me of its age there.

No matter what, emacs still feels "alien" in my OS's desktop interface with its UI concept, and never fully integrates. That's fine if you don't want it to integrate, but I actually like some concepts of my OS's UI a lot, and miss them in emacs.

And elisp is not a very good language, born of a time where programming languages still had a long way to go (at least in the mainstream, academically it always seems a bit different to me). They are actively trying to fix things, e.g. the adoption of lexical binding, but the scope of this effort also shows how emacs is a very big ship that is hard to change course.

Someone else mentioned lack of proper multi-threading in another comment now, and this is also very noticeable.

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

#33
post #14
post #4

Earlier quoted context omitted.

With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud). I don't want to master an editor anymore. I want to get work done. Pretty much the same with LaTeX. When I want to improve something in a doc, I look it up and do that. When I go back to the doc later, I don't always remember what that magic meant. But that's ok, I'm writing a doc. I'm no…

Just out of curiosity, which editor do you use? Overleaf?

Yes, Overleaf. I'd always had LaTeX envy but when faced with installation and configuration, I gave up again and again. Overleaf solved all that.

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

#34

I am also a 10+ year GNU Emacs user. I haven't customized it beyond font size and a few settings. I even use the default theme. Other users seem to go crazy and try to make it into a spaceship. Then they claim that it takes a lot of time to customize it. It mainly is very different to operate from all programs and window managers that we are used to these days, and people perceive this as a wrong and try to "fix" it…

Totally with you on this. I’ve added some stuff for coding in Python, but really minimal changes. 10+ years later I’m still happy and use it daily.

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

#35

I am also a 10+ year GNU Emacs user. I haven't customized it beyond font size and a few settings. I even use the default theme. Other users seem to go crazy and try to make it into a spaceship. Then they claim that it takes a lot of time to customize it. It mainly is very different to operate from all programs and window managers that we are used to these days, and people perceive this as a wrong and try to "fix" it…

While making notes about config & tips for various linux software, the bar in my book is actually wether you can live with the defaults and how little tweaking something needs.

It's the exact opposite of sinking costs, and rather focus on "good enough" because you often end up switching or changing stuff soon enough anyways.

So more like how fast can you just go from default install and choose the sanest defaults and not spend time on tweaks / unix pr0n. Install what you need just in time etc.

It makes even more sense when using defaults on several remote systems, kind of like just using vi.

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

#36
post #3

Here is an idea: Stop adding crazy marcos and customization and use it like an editor instead of an OS. I understand this is a very controversial idea, but I have learned that since I'm switching machines and using remote boxes all the time, customising everything 100% to my liking is neither possible or worth the effort. This of course requires the emacs team to make the barebone emacs a little bit more functional.…

Why would switching machines prove to be a hindrance to customisation? The configuration files are still nothing but source code text, which could be version controlled and deployed anywhere with little automation, it's really no different from deploying software that you are writing.

Customising everything 100% to my liking is not only possible, but also takes very minimal effort. Detect if it's home desktop, or work laptop, or something completely new, and do something accordingly, what is complicated about a conditional block? Elisp is a normal language with all normal logical abstractions available.

I concede about remote box, I mostly work over ssh in terminal too. Except Tramp is also like really easy. To the point that if I need to use git, I almost always use local Magit over Tramp. This way I am not compromising, Magit is best in its class kind of tool, and I don't even need to install Emacs in remote box to use that.

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

#37

I wish there was a solid competitor to Emacs, but the thing that keeps me coming back is that I have the time to tinker with it a lot and the community is great. Vim and Vscode have some valiant maintainers of projects, but from what I've seen it's nothing compared to the big Emacs projects, especially Org mode for which I haven't found a reasonable alternative in Vscode. However, I don't like fact that most of the e…

For what it's worth, Emacs Lisp clicked for me properly when I learned Common Lisp and then threw out what I knew and treated it as a cousin language (which it is) with some different design elements and read the documentation.

However, learning two languages to learn one is a big ask, I just had no choice on CL thanks to a college course (and have no regrets, easily my favorite language to program in even if I never get to use it professionally; most of my classmates would vigorously disagree).

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

#38
post #18

So, that's NOT the sunk cost fallacy. If you are still getting benefit from the cost, it's not sunk*. This is just not wanting to invest time into a new system while you're still productive in the current system. A sunk cost would be like, "Well, I spent $100 on this steak, so I'm going to finish it, even though the next bite may make me vomit." In that case, you paid for the steak, it cannot be returned half eaten,…

I think it's an overused concept because it's exemplary of a larger cultural issue. People praise 'openness' and optionality, (not just in software tools), and are skeptical about any form of commitment simply because it closes off some paths.

In programming it comes up a lot with opinionated programming languages, IDEs etc. Environments like Emacs with their idiosyncrasies and age tend to be disregarded because they aren't all things to all people.

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

#39
post #4
post #2

I'm in a similar boat as in the first quote: Have used emacs for decades, glad that I do, can't imagine switching... don't think I would recommend it to anyone new, unless they are really open about learning something entirely different. Emacs seems to be in the same position as LaTeX: Outdated paradigms that would probably need an entire redesign from the ground up to start "making sense" in the modern world. This s…

With respect to LaTeX, I only started to use it semi-recently in the cloud and I'd recommend it to anyone (but only in the cloud). I don't want to master an editor anymore. I want to get work done. Pretty much the same with LaTeX. When I want to improve something in a doc, I look it up and do that. When I go back to the doc later, I don't always remember what that magic meant. But that's ok, I'm writing a doc. I'm no…

The problem with LaTeX is that it isn't well-designed enough that you can just use it without thinking about the magic.

When stuff is not up to scratch (image is placed incorrectly, spacing in your table is wrong, your diagram has an incorrect alignment, etc), the error messages suck, and you often need to figure out what the magic does to be able to fix the issue.

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

#40
Every so often I would start my Emacs config over from scratch. I might port over some old defuns from the previous, eventually, but I would always endeavour to try the latest tools and best language configurations. Consistently I found myself using Emacs and sticking to it because it offered the best developer experience.

And then came Microsoft's Language Server Protocol. Emacs was late to adopt it, and still has generally spotty support for it. This has caused me to stop using it, almost altogether, as Emacs is objectively inferior because of its poor support for LSP.

Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?

And then when they do work, the packages often drift and break. I had C# working quite well with lsp-mode and OmniSharp, and then I updated Emacs. Without any changes to my configuration the experience has become atrociously slow, and apparently this is due to a known and recently introduced bug in Emacs support for C-style modes.

I strongly recommend other Emacs users shake the sunk cost fallacy and just try the competitors.

Post reply on HN