Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

karl-voit.at

Post reply on HN
Print view View original

81–90 of 267 posts

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

#81

Post by BeetleB »

Jtsummers wrote: post #60
BeetleB wrote: post #55

Earlier quoted context omitted.

> Fortran has seen major changes over the 64 years it's been in use. And yet most Fortran programmers reject/ignore those changes and stick to Fortran 77. When I was in academia, I couldn't find a single person writing Fortran code in anything newer than 77.

My experience with that convinced me that many academic Fortran users are cargo cult programmers to the extreme. They're "taught" by examining the code written by their advisor's advisor's advisor who may have properly learned F77 back in 1980, but no one else did. Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66). Specifically, that's the version that got structured programmin…

> Even then, FORTRAN 77 is a major change over FORTRAN (1957 and even the later FORTRAN 66).

That's because FORTRAN is one of the oldest languages, and you'd expect lots of changes as the whole field develops. If you use that as a metric, most languages will appear stagnant. Python hasn't changed much in the last 20 years, for example.

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

#82

Post by pkulak »

Jtsummers wrote: post #31
pkulak wrote: 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…

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!

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

#83

Post by iLemming »

playcache wrote: post #8

This is why I don't bother with emacs, I just don't have the time to sink in the first place. Now that I have a young family and hobbies outside of work, I don't have the time to spend hours fixing and tinkering a setup or learning an already opinionated set up like spacemacs etc. I just use an IDE which is already set up with good defaults and I have a well settled vim config for driving remote machines or changing…

> This is why I don't bother with emacs, I just don't have the time to sink in the first place

I use Emacs specifically because it's a huge time saver for me. Pretty much almost every day, I find something repetitive that I don't want to do manually.

- Need a link on GitHub for the current line in code?

- What if the same line but in a different branch?

- What if you're already browsing code on GitHub and want to check out this specific file (in specific commit) but in your IDE?

- I want to send a YouTube link to my colleague, but I don't want to separately copy and paste, first the link, and then its description; Emacs helps me do that instantly.

- I have two pieces of code or text. I want to diff these snippets quickly.

- I am not a native English speaker; how can I quickly translate any word or a phrase and even hear its pronunciation?

- How can I quickly find a definition of a word or its synonyms?

- I use and love Grammarly, but I don't want to use their stupid editor. And I don't want to copy and paste the text all the time; I perform Grammarly checks while in Emacs.

- I want to find packages on npm, maven, clojars, etc, without opening the browser and typing.

- I want to select a piece of code and search for it on GitHub, and Emacs would make sure the language is properly set.

- I want to convert between different units quickly, or generate UUIDs, or validate JSON. Even when I'm offline.

- I want to find (recursively) all the files that e.g., bigger than a certain size and were created between April and June and rename them all or delete them.

- I'm going through my notes and see that ticket #1346 is done, and I want to trigger the state change without ever going to Jira, GitHub, etc.

And there are many, many examples of things like that. And sometimes it's not even about the time. It is far more enjoyable that way. It feels empowering. You don't have to think about some trivial things and can focus on what's important.

There's not a single [other] tool that makes me feel like I'm in so much control. And for a software developer is very important to feel being in control. Or it starts slipping into a burnout.

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

#84

Post by alex_smart »

_huayra_ wrote: post #79
rich_sasha wrote: post #30

Earlier quoted context omitted.

I have found it very difficult to pickup elisp, but the latest concerted effort worked. I found learning it to be a very fulfilling experience.

Was there any resource that help you get over the understanding hurdle?

Emacs comes with everything you need to learn emacs-lisp. Take some time to familiarize yourself with the help facilities* and then jump over to info, start with "Emacs Lisp Intro" and eventually continue with "Emacs" and "Emacs Lisp".

* At the very least, familiarize yourself with "C-h f (describe-function)", "C-h v (describe-variable)" and how to read info pages. To view what other help facilities emacs provides glance over "C-h ? (help-for-help)".

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

#85

Post by iLemming »

na85 wrote: post #69
blacktriangle wrote: post #19

Earlier quoted context omitted.

Emacs gives you back what you put into it. There's absolutely nothing wrong with using it at a very basic level, and getting to that point takes minimal time. There's a 15 minute interactive tutorial linked from the start screen at which point you're fully able to get work done. You can then reach for other goodies like Org, Magit, various interactive shells, tetris, whenever you want/need. I probably used Emacs for…

I say this as a 10+-year emacs user: The "15 minute tutorial" is emblematic of everything wrong with emacs and its community. Just make CUA-compliant keybinds the default, and you'd draw in so many more users. The ideal tool is one that you can start using right away, and incrementally dig into as you descend into madness/poweruserdom. The idea of having to waste 15 minutes before you can even start working in emacs…

> The ideal tool is one that you can start using right away,

There's a strong correlation between things that are not so easy to get into but the gained efficiency later. Conversely, very often, something that is very intuitive off the bat starts feeling cluttered and not very efficient later.

Imagine if you go to a nuclear power plant control room (or the cabin of an industrial excavator) and tell them - "Jeez. So many knobs, buttons, and switches. Why can't someone design a single, incredibly intuitive interface with a huge touch-based display?" For them, those knobs, buttons, and switches are probably the most efficient way to operate their machinery, even though initially, it requires training, certification, etc.

You cannot prioritize both - for the novice and the professional at the same time. You either convince beginners to learn the tool or make a simplified version of the tool for beginners. But it will never be an ideal tool for a hardcore professional.

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

#86

Post by iLemming »

Koshkin wrote: post #63
nine_k wrote: post #53

Earlier quoted context omitted.

If only VSCode had sane buffer control, and the idea of buffers. I use VSCode with Emacs key bindings for certain development. The lack of uniformity inconveniences me a lot. But indeed, VSCode is the closest thing to Emacs in its spirit.

JavaScript: "Lisp in C's clothing" https://www.crockford.com/javascript/javascript.html

No, it's not. It's nothing like Lisp and will never be, simply because it misses the biggest (arguably most important) feature of Lisp - homoiconicity.

But sure, if you squint your eyes - pretty much every single modern programming language would be "like a Lisp" Why? Because there's not a single programming language in use today that was not influenced by ideas first pioneered in Lisp.

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

#87

Post by TchoBeer »

User23 wrote: post #15
CalChris wrote: 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…

Imagine a carpenter saying, "I don't want to master my tools, I just want to build things."

It's more like a carpenter saying "I don't want to master my car, I just need to be able to get from place to place". A mathematician isn't payed to typeset papers, they're payed to do mathematics and typesetting in LaTeX is just a means to an end.

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

#88

Post by krylon »

nine_k wrote: post #53
dleslie wrote: post #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 g…

If only VSCode had sane buffer control, and the idea of buffers. I use VSCode with Emacs key bindings for certain development. The lack of uniformity inconveniences me a lot. But indeed, VSCode is the closest thing to Emacs in its spirit.

I haven't given them a close look, but there is a project called "zile" that - AFAIU - aims to create an emacs-like editor using Lua instead of Lisp. Which sounds amazing to me.

Also, there's another project to replace emacs' lisp interpreter / bytecode VM with GNU Guile, which started out as an embeddable Scheme interpreter, but apparently these days it is a JIT compiler that supports Scheme, Javascript, and elisp. Which means Guile-Emacs could absorb all of that elisp code without a problem, probably make it run faster, too, but also open the door for people that don't feel comfortable with elisp. More importantly, maybe, this project could bring people from different language communities together.

Again, I have not spent much time looking into the project, so consider all of what I'm writing hearsay. But things are happening.

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

#90

Post by zibzab »

ta_emacss wrote: post #49
zibzab wrote: 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.…

i just copy the .dot file and launch emacs. in a few minutes without touching anything i have the same environment.

Yeah, that's me 3-4 years ago.

Then I ran emacs on a new machine for months before realising my .emacs refused to load correctly because I had not installed the correct fonts and cscope. So dot files are not foolproof.

(Throwaway account to discuss emacs? Do you live in a vim-only country?)

Post reply on HN