3 ms·

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

by pkulak 5y ago

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, and eating more of it will bring you zero benefit, so the rational behavior is to not eat more of it. EDIT: It's not a "fallacy". It is still a sunk cost. My mistake.

Jtsummers 5y ago
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).
- pkulak 5y ago
  You defined a sunk cost properly, but that's not the same as the "sunk cost fallacy". To abuse my original example some more, when you are hungry, the steak is still a sunk cost, but it's obviously not a "fallacy" to eat it then. EDIT: Just realized what you are responding to. I'll edit my post. Thank you!
Barrin92 5y ago
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.
bborud 5y ago
I think a good simile would be that using Emacs is a bit like owning an old car. It breaks down more often, and when it does, your Google search results for results lead you to crusty websites that are skinny on solutions that would be applicable for you. So you end up lying to the floor with parts strewn around you more often than you'd like to. And what you really want to do is go places in your car (ha...ha....ha) than be a mechanic. I've programmed Go using Emacs for 4-5 years (and I've used Emacs for 30+ years). To be frank: my old Alfa Romeo from the 1980s breaks down far less often than the Go tooling in Emacs. Or the Java tooling before it for that matter. It's not that I no longer like Emacs. It is just that I like programming more than I like doing redneck-repairs of Emacs.

by pkulak 5y ago

Jtsummers 5y ago

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).

pkulak 5y ago
You defined a sunk cost properly, but that's not the same as the "sunk cost fallacy". To abuse my original example some more, when you are hungry, the steak is still a sunk cost, but it's obviously not a "fallacy" to eat it then. EDIT: Just realized what you are responding to. I'll edit my post. Thank you!

Barrin92 5y ago

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.

bborud 5y ago

I think a good simile would be that using Emacs is a bit like owning an old car. It breaks down more often, and when it does, your Google search results for results lead you to crusty websites that are skinny on solutions that would be applicable for you. So you end up lying to the floor with parts strewn around you more often than you'd like to. And what you really want to do is go places in your car (ha...ha....ha) than be a mechanic. I've programmed Go using Emacs for 4-5 years (and I've used Emacs for 30+ years). To be frank: my old Alfa Romeo from the 1980s breaks down far less often than the Go tooling in Emacs. Or the Java tooling before it for that matter. It's not that I no longer like Emacs. It is just that I like programming more than I like doing redneck-repairs of Emacs.