Comment by segmondy | Hacker News Reader

Comment by segmondy | Hacker News Reader

Parent Full thread

That's the wrong way to look at it.

Anything you're not good at it is going to slow you down. The question is that even tho you might be slow, if you put in the effort, learn it then get good, will the savings and speed up make up for the initial slow down?

I'm a vim fan and won't try to convince others. But I personally believe that the answer is yes. One of the secret to being successful with vi is that of mindset. You need to have a positive mindset that it's worth learning, you need to commit to learning it. I learned vi when network speed was very slow and systems didn't have enough memory. It was faster than any other editor. So I had the mindset that I needed to learn it. if I was starting out today, it probably would be hard when you have editors like vscode.

I have typed and used computers everyday for 25 years non stop and I have no issue with my fingers and I believe a major part of it is using vim and my fingers not having to travel and move out to find a mouse or hitting Ctrl+ keys.

Another way to look at it is: what fraction of the time are you typing versus thinking? If it's less than 20%, then a faster editor will probably not speed you up by a significant amount.

Typing and thinking are almost the same thing to me. I'm either writing code, or bullet lists with things to do, concerns to take into account, things I've learned, etc. Text file is an extension of my memory, and a place to distill, manipulate, and organize my thoughts.

Vim won't speed up your typing. It'll speed up your editing. Adding/discarding/modifying large blocks of text, or spread-out blocks of text. It'll let you think in terms of moving this block there, replacing these words, duplicating these patterns, etc. The efficiency increase comes, in large part, from allowing you to make steps that are closer to how you think.

And even if we're talking about 20% of your time, improving that 2-10x is nothing to shake a stick at. 20% of 10 hours is 2 hours, if Vim makes you edit 2x faster, that's 1h saved, per day. And that's without accounting for other work you could move to your suddenly more efficient plaintext mode, and the work you don't even consider doing because your editing experience is too painful (it sometimes work the other way too; there are things I won't do in Emacs, but I will in IntelliJ, where project-wide, language-aware refactors can be done with two clicks in full confidence that nothing will break).

I generally agree as somebody still fairly new to development. I'm about 6 years into focusing in computer science, and early into the process I heard about vim and emacs. I knew that it wouldn't be necessary to use either while going through undergrad, but I decided to learn enough vim to be functional just because I wanted to understand.

Vim still isn't my exclusive dev editor, but it has almost become my exclusive terminal editor. Learning older technologies may not always be top priority, but it can do a large amount to enrich your personal perspective- particularly if you discover the niche where its usefulness is best utilized (and like you mentioned, if the amount of time to get up to speed will save you proportionate future time).

Wait a minute, wasn’t ed faster at that time? :)

When I started using Unix (36 years ago) I could open a file in ed, make a small change in the file, and save it back to disk, faster than it took vi to startup.

Not to mention Eight Megs And Constantly Swapping.

Eight Megs? On the machine I was using 36 years ago, each process had a limit of 64 KB for code + 64 KB for data. It was 8086 based and that was called the small-memory model. Later versions of the OS added support for the medium-memory model which could support 192 KB of code + 64 KB of data.

Reply on news.ycombinator.com