Everyone Who Tried to Convince Me to use Vim was Wrong (2010) | Hacker News Reader

Everyone Who Tried to Convince Me to use Vim was Wrong (2010)

yehudakatz.com

78 pointseranation75 comments

I really like Yehuda, but I must say that I always found this article personally annoying: I was one of those people trying to convince Yehuda to use vim (going way back to like 2006 when we lived in the same town and I was consulting for a company he worked at), and was probably one of the earlier people to really argue with him about using vim, and I can guarantee I wouldn't have said any of the things in this article.

I can be certain of that, as I still use actual arrow keys to this day: I started using vim well over a decade ago, maybe almost two, and I simply never got around to using hjkl. There is thereby no chance in hell that I would have told him to turn off the arrow keys (although we both know someone who probably did, who worked with him much more closely, but he has a personality type that requires him to "whole hog" everything he tries ;P).

It also has taken me forever to get around to learning even things like "cw", which I only just integrated into my behaviors a year ago. It's even a running gag on the IRC channel I spend most of my time on (and where Yehuda used to hang out) that vim is something that everyone knows some barely overlapping subset of the keyboard behaviors for ;P.

It is true that I would have been telling him to use console versions of vim, but my definition of "console" has always had "mouse support" as a key requirement: until just about two years ago I always had "set mouse=a" turned on by default, which gives you the ability to click around in both command and input modes, the ability to click and drag to automatically enter visual mode, and (in particular) fully operational mouse wheel scrolling support.

I thereby can only imagine that Yehuda simply got such strong pressure from some subset of the people who were talking to him about vim that it got him so generally angry about the whole situation that is "use vim" that by 2010 he got to the point where it just seemed like "everyone" was telling him to "whole hog" vim; I thereby can happily appreciate why this article got written the way that did.

However, I think people repasting it around now may end up with the wrong impression of "people who use vim" as a whole by going back and looking at Yehuda during this one moment from 2010 and then using this article as a guide to something important today about that community. (Which explains why I didn't ever comment on the original article, but if people are going to bring it back, I feel the need to do so ;P.)

This is a great article. It made me move to Vim after years of replacing and optimizing every component between my brain and my code.

I could think fast, but although I was the "fastest kid in the block" when it comes to writing code, I always wanted more.

In a pedantic process, this is what I did go through, over the time span of around 7 years:

* Learning to touch type properly.

* Testing out many keyboards (I settled on a clone of an apple keyboard that has no numpad, short keystroke).

* Testing out Dvorak, Colemak, for more than a year, only to return to QWERTY because it is omnipresent.

* Optimizing IDE and editor shortcuts, keybindings, and live templates

* Trying out every editor under the sun, including Emacs, taking care to leave Vim out (because I held it as "not worth it"). I remember trying out a very very alpha SublimeText that didn't have undo -- funny how things go.

* Optimizing the colorscheme and button and canvas layouts of IDEs. I went for blank - hide everything and leave only the canvas visible - in Intellij, Visual Studio, and Eclipse.

Eventually, I read Yehuda's article 2 years ago. I took the same approach, and it's been amazing. I have never felt my brain connected to my editor this well.

I still "use Vim my own way". I save with CTRL-S, copy-paste with CTRL-C/V for example. I'm fully aware of the proper way to do it, and I do that when I'm ssh'd in a server. It is embarrassing but it works. I'm slowly shaving away these embarrassing usage scenarios and becoming a 'pure' Vim user.

Today, I write entire products and libraries at amazing speed (this includes creating files and directory layouts with NERDTree, jumping to files with CTRL-P, etc - no mouse whatsoever, which is very hard to do in a traditional IDE).

I would go further and say that in certain situations (dynamic languages) Vim does become the Holy Grail for me; and I owe that to Yehuda.

Thanks, wycatz!

Vim is sort of like C++: everyone knows their little subset of it, and everyone knows a different subset. It's common to watch another Vim user do something and be like, "how did you do that!?!?". And it's in their muscle memory, not their conscious memory: they need to repeat it and watch which keys they hit.

What are these people doing that makes such miniscule micro-optimizations of text-editing performance matter so much?

Me, I type code. I copy & paste code. I do global searches on the source tree, and every now and then on a single file. The editor has file-type sensitive syntax highlighting, which is nice enough but not all that important. And that's about it: that's all you need to work as a professional software developer.

So when I hear people getting all worked up about these antique editors, it sounds a lot like listening to a bike snob go on about fixies.

Sounds like a classic case of pg's "Blub paradox"

http://www.paulgraham.com/avg.html

I don't see the similarity. Would you please substantiate your claim?

Going to the article you cited, the ultimate magic appears to be the use of macros. Defining composable (mini-)languages that are appropriate for a given domain is indeed very powerful and produces significant reductions in the amount of code typed to solve the domain problems. By the way, ASTs for domain-specific languages can be implemented in most common languages via very mundane enums, unions and switches. But I digress.

"Text editing" problems are much simpler than "build an e-commerce web-site" problems. While both Lisp and Vi happen use macros, this feels more of a coincidence. The actual need for macros is much higher in the ViaWeb scenario.

Allow me to reiterate the OC comment: What is it that a ninja text editor actually does with his super-human powers?

OK, I'll bite. I am a sometime programmer, mostly a data analyst. I acquired Emacs less than two years ago, mostly because it could highlight both LaTeX and R code for me, and allowed the evaluation of R code in an attached buffer.

It was awful, I tried it twice before I actually succeeded in switching to it. But eventually, I got used to all the arcane keyboard shortcuts, began to appreciate the power of a program that allowed me to interact with everything (well, except for ncurses based terminal applications) and I became hooked.

I firmly credit Emacs for making it easier for me to switch to new languages, I've learned more about GNU tools from info than from anywhere else, and I absolutely adore keyboard macros (as they always felt like something a program should be able to do). So, for me at least, the benefit of learning this arcane program was that it exposed me to a method for learning new things while still having some level of skill in the environment.

That being said, I really need to learn some vim, for the logging into a remote server with no permissions scenario.

He basically said he uses a text editor for X subset of text editor features and can't see why Y set (where Y > X) would be of any more use to any one. That's classic Blub. Until you learn them and use them you can't really "envision" why they are any more useful than your current workflow.

I can envision all kinds of useful tools an editor might offer; I've implemented a few of them. What I can't imagine is how any number of fancy editor features would ever add up to significantly higher productivity, given that every programmer I have ever met spends an order of magnitude more time reading, thinking, and discussing than actually editing code.

It's not about saving time per se, it's about saving context switches and wasted brain cycles.

I don't disagree with that last sentence, but even acknowledging that, getting a whole lot more editing done in a whole lot less time, using significantly less keystrokes, makes for a much more enjoyable (and almost by extension: more productive) working experience. Not many things in programming are as soul-sucking as repeatedly having to bash the same keys or mousing and clicking around to translate your thoughts into working code. I think you are really underestimating the usefulness of some of the things you can only do with command-mode editors such as vim, if you think their only merit is saving a few seconds of typing.

It reminds me of this passage from book 1 of Chuang Tzu:

"There is also a bird there [in the bald and barren north], named P'eng, with a back like Mount T'ai and wings like clouds filling the sky. He beats the whirlwind, leaps into the air, and rises up ninety thousand li, cutting through the clouds and mist, shouldering the blue sky, and then he turns his eyes south and prepares to journey to the southern darkness.

"The little quail laughs at him, saying, 'Where does he think he's going? I give a great leap and fly up, but I never get more than ten or twelve yards before I come down fluttering among the weeds and brambles. And that's the best kind of flying anyway! Where does he think he's going?' Such is the difference between big and little."

http://terebess.hu/english/chuangtzu.html#1

I actually agree with marssaxman (and I'm not certain that Chuang Tzu is equating big with good and little with bad), but clearly whether the choice of editor is significant is a question of perspective, and everybody is going to have a different one. I used to care quite a bit about editors. Now I see a lot of our industry tool fetishism as rather unproductive. But I have seen people use the hell out of Vim and it's really quite impressive. Just not a skill I personally feel a strong need to develop.

It's not a skill most vim users care whether you develop, either. I don't mean that in the aggressive way it may sound.

Vim users like vim for some legitimate reasons (e.g. ubiquity) and some illegitimate reasons (e.g. speed). But to my eyes, it's typically the users of heavy IDEs who seem to be insecure in their choice, to the point that they get offended by the fact that vim works for others. Take marssaxman as a case in point.

I'd find it easier to agree with you if it didn't feel like the only aggressor in the editor wars is Vim. But ultimately, "vim is amazing" blog posts are about as interesting as monad tutorials. They're just verbal droppings excreted by young minds that are easily blown. Nothing to get worked up about, but sometimes fun to pick through.

We disagree on which party is the aggressor, but agree on the rest. As a vim user, I don't think vim is amazing. As a NetBeans user, past Eclipse user, and past Visual Studio user, and sometimes Sublime Text user, I don't think they're amazing either. Though Sublime Text 2 is quite well done.

As a clojure hobbyist, Light Table might one day be amazing. But it's not yet.

I don't think it's a matter of insecurity. In the decades since vim was released, we've made drastic improvements in UX design that have made computing much more accessible and intuitive. (And we're still moving forward at a rapid rate — just look at the stuff that people like Bret Victor and Chris Granger doing!) And yet, so many programmers are adamant on sticking to 20th century editors and obscure key commands, even sometimes (sometimes!) at the expense of usability. I don't think it's particularly offensive to wonder why such old tools are still so popular, especially when for most people the thinking part of programming is what takes the most time.

Additionally, your tools shouldn't define you as a programmer, and yet I often see people getting shamed for using an IDE instead of vim/emacs/whatever.

But there's this misconception that we who use vim are simply ignorant of these amazing IDEs that have changed the way everyone program and which will make your coffee in the morning.

I've used IDEs, a lot. And not decades ago, I try new IDEs out all the time. When I write Jenkins plugins it's in NetBeans. I have tried out SublimeText 2 quite a bit. I used to write games so I spent all my time in Visual Studio with Visual Assist X.

Given all that, when I want to write some C++ I fire up vim. Not because I'm unaware of all the IDEs out there and all they can do. But because I'm very efficient using vim, find, grep, sed/awk, etc.

It's not offensive to wonder why such old tools are still so popular, but it's offensive to assume that they're popular because their users are ignorant. Maybe you just haven't gotten it yet (and won't). Or maybe we just have different use-cases. The vim commands obviously aren't obscure to me since I know them.

I agree that your tools shouldn't define you as a programmer. Clearly I wouldn't shame anyone for using an IDE, since I do all the time when it makes sense to. The problem is that many IDE users just can't accept that I use vim because I work well in it, not because I think it's trendy. I can work well in any environment you throw me into, because 90% chance it has vi, and otherwise it has Notepad. Most VisualStudio users can't say the same. Fine, they don't think that's an important skill, I can accept that, just don't tell me it's not important to me.

Or, on the contrary, a classic case of what psychoanalysis calls the "narcissism of small differences", ie. getting a superficial sense of one's own uniqueness based on marginal and superficial differences.

As in: "I use Vim, I'm so much better than those blub Sublime Text programmers"

That isn't the right way to look at it. Tools can do things more or less clumsily, more or less efficiently.

I do all those things in vim. There are things which editors can do which vim is quite bad at, but you apparently don't do any of them.

Yeah, I feel like actual typing makes up only a small fraction of the development I do. I spend much more time thinking about code and structure, doing research, debugging, than just typing out brand new lines. But I guess it depends on the kind of project. I'm working on some more algorithmic stuff in game dev, whereas I guess someone making a website would want to be slamming out html asap.

Extra keystrokes add up over time. I wonder how much time I've saved implementing * and # into my movements. Considering that I was either C-f or C-b -ing (or in my earlier days, j and k -ing) through my files, probably a shitload.

I can cut with a blunt knife, and it might not slow down my cooking appreciably or at all, but I'd rather just use a sharp knife. (And my wrists will thank me for it, if I do a lot of cutting.)

Even if Vim keybindings don't make me any more productive, they sure make my life more pleasant.

> What are these people doing that makes such miniscule micro-optimizations of text-editing performance matter so much?

This is not about time optimisation[0]. If your current editor does not feel like a hurdle to you, then certainly don't change it (you have the right to be curious though :-)

[0]: https://news.ycombinator.com/item?id=5448983

You should never listen to anyone advising to use only bare-bones console vim without the mouse or cursor keys, it's simply masochistic and doesn't contribute to your efficiency learning vim at all. Only if you expect to ever be using unix vim remotely through a terminal you should be aware of hjkl for navigation and visual mode for block selections. Any other constraints you impose on yourself are philoshical, if all you want is vim on OSX/Windows/desktop Linux.

That said, after you get comfortable using insert mode with just the most basic command mode stuff, I would highly recommend incrementally expanding your use of command mode. Learn about yank registers, movement units (words, sentences, brackets, quoted text), how to repeat commands, how to record and play macro's, split buffers and how to move around buffers and windows, etc. You could start by adding one command or feature each week and go from there.

If you never invest time expanding your vim knowledge and habits, there really isn't much of a reason to use vim at all. The whole point of vim is that it has so many crazy productivity-enhancing features. If you don't want to spend time to learn any of them then just don't bother, but realize that no 'easy to use', fully GUI-driven editor could ever come close to the editing efficiency you can theoretically get using a command-mode editor such as vim. There really is truth in what people say, once you master the most useful aspects of vim, you can never go back.

Some of us do use bare-bones console vim because we're using it remotely through a terminal. Or because, god help us, Solaris still doesn't install vim by default and we're stuck using plain old vi (at least on a customer's server, where I can't just go and install vim).

That's why I learned vi back in 2004, and while I still get tripped up when backspace doesn't work in insert mode because of some terminal setting, using hjkl has become second nature. There's a lot to be said for absolutely having to learn something.

Once I learned enough to be proficient doing simple editing, I switched to using gvim on my Windows machines, and then learned more as I found myself wondering if there was a better way to do something. Now I do virtually all of my coding in vim. The only downside of this I've found is that I'll occasionally C-w when typing in a web form and close my tab instead of deleting the last word.

I never got interested enough in emacs to learn it, but if I find myself in a situation where it's what I need to accomplish something I'll learn it. Need is a powerful motivator.

EDIT: I should also note that learning vi[m] on a computer with a Sun layout keyboard makes the idea of switching into command mode a lot more palatable. Esc is right there next to the 1, rather than somewhere in the next state.

If you ever get interested in a lispy language you'll want to use emacs. You're fighting upstream trying to use vim (or anything else).

Yes, if you're using vim through a terminal, or have to use vi on systems like Solaris, it's most definitely useful to know bare-bones vi. If you're on such a system, it's often the only thing you have besides 'ed'. Been there, done that (I found HP/UX possibly even worse than Solaris in terms of usability, unbelievable as it may sound ;-). For the vast majority of newcomers to vim, none of this matters though. They will be using gvim, MacVim or win32 vim exclusively, and probably wouldn't be very comfortable working on a Solaris or HP/UX box remotely anyway. SSH-ing between Linux or OS X boxes, or using a decent Windows terminal client, there really isn't any problem if you use the arrow keys, and if all you do is local editing on a desktop system, using the mouse to select text is a good way to start before learning all the different ways to cut/copy/paste using command mode.

I use the arrow keys in an ssh session all of the time, why do you need to use hjkl? What does it interfere with?

Sometimes you're in a situation where your arrow keys don't match up with your terminal environment variable, and when you go to use them, it spews control characters all over your screen. I remember we were using Reflections as a terminal emulator, talking to hp-ux servers. I was helping out someone using vi. I had to keep telling him to keep his hands off the arrows keys because whenever he used them, it had that problem. I guess the short answer is: sometimes the arrow keys don't work. In some situations, the arrow keys LOOK like they're working, but VI doesn't know that you moved the cursor, and things get all screwed up. So I just don't trust the arrow keys at all. VIM lets you move around in INSERT mode, which is not something I'm used to either, because you can't do that in VI. Trying to use the arrow keys in insert mode in VI is just another mistake I see people make. Just ends up inserting control characters into the file. From experience, I just don't use arrow keys in VI/VIM.

So now I know about the existence of ci " . I feel like half my life has been wasted by not knowing it.

Hah, no doubt. Not sure if it's good or bad each "I just learned vim" article has some random command I'm totally unfamiliar with I can't believe I haven't used. Obviously I'm just a vim user, not a power user.

Just play some nethack, and you'll be completely comfortable with the hjkl movement keys in no time.

Yep, having to play Crawl a few minutes a week is like piano lessons for my son now ;) Someday he'll understand why.

I just can't use them. I activate the number-pad every time I play.

That said, I'm more of an emacs guy.

I did this, then I started missing the yubn diagonal movement in vim. ;)

I was fortunate enough to pick up vim in my teenage years on the job where I worked on remote unix machines. I still learn new stuff all the time but using vim is kind of like speaking, breathing, or typing to me at this point, and I don't really remember the initial learning and struggling phase anymore. I feel pretty lucky in this and a) I don't care if other people use vim, really and b) I have a tough time empathizing when people who want to use it get so emotional about how hard it is to learn. It's kind of like hearing someone complain about how difficult English is or learning to type and getting in debates over if it's worth learning. To me it's pretty obvious that I could not live without it. But arguing about it is irrelevant to me and I can only sympathize in the most abstract way because I don't really remember "learning" English or typing. But I'm sure it would be extremely hard to pick up at this point in my life from scratch.

Much more popular this time than when previously submitted about a year ago: https://news.ycombinator.com/item?id=4088248

And three years ago: https://news.ycombinator.com/item?id=1559074

This belief that because you use something, everyone else should too is so self-involved it's not even funny anymore.

_________________ isn't for everyone. That's ok.

Arguing over the preference of tools/languages/frameworks creates distractions of "are you missing out?" instead of the real world needs of "customers don't care what you code in, or what you code with".

Most tools, languages, and frameworks all have their pros and cons and when all is said and done, most of the popular and not so well known ones are perfectly suitable.

Tools are about as relevant now as buying a hammer vs a high end hammer. You still have to know what to nail, and why according to a more clever architecture, not using clever nails no one knows how to use after you're gone.

Developers spend so much time optimizing their own experience developing that I can't help but wonder if the software they end up writing ends up missing out -- not in technical or architectural flexibility, but solving the problem as best as it could be for the end user -- from their world -- in their terms of getting more done with less effort.

I've tried and not picked up Vim as well. I did notice I had better luck at it when I was using vim with a small personal project that allowed me to learn vim as I went, instead of needing to be at 100% speed and efficiency immediately.

If you have 15 minutes and you're interested in vim, go to your terminal or unix shell & enter the command vimtutor.

The tutorial there will get you going really quickly, especially in combination with reading Yehuda's article. It's also worth checking out this distribution https://github.com/carlhuda/janus

It's easy to install and comes with a bunch of great plugins. One of the huge benefits of vim is the plugin community.

The most productive editor must takes minimal number of physical actions (like keys to be pressed) to achieve desired result.

My Sublime-2 with Brief key emulations is like that now. If it takes 3+ keys presses to switch between "modes" or accomplish simple and frequent operation - that tool is for masochists, not for creative productive people.

Most people I've talked to who've gotten into vim have gone through the exact opposite flow:

1. Tried vim in college, only ever used insert mode + <esc>:wq 2. Discovered Textmate or similar and loved it; only used vim for the occasional remote editing 3. Tried to get into vim on the advice of friends, but always ended up reverting to using it like notepad in insert mode because it was easier than looking up the command they needed. 4. Went whole-hog into vim one day, turning off arrow keys, and immersing themselves in it. After a few days, they were as productive as they were in textedit, and after a few weeks they had drunk the kook-aid and were more productive than previous editors.

So, while I don't condone badgering a guy to learn this way so much that he writes an angry post, I would argue that going all-in on Vim is the best way to learn it for most people I've talked to (myself included).

This post set me thinking about why I prefer acme to vi. They're both derived from ed, and nowadays they both know about the mouse. So how do they differ?

Vi splits insert and edit modes by time: you hit keys to toggle between them, letting you move the mouse less. Acme does it by space: blue bits of the screen hold commands, beige ones hold text, letting you remember less. To repeat a command in vi, you have to remember what you did. In acme, you look for it and click it again.

Acme lacks an exact equivalent to vi's w, t and other motion commands. However, double-click does "select what I mean", commands operate on the selection by default, and mouse chords do copy and paste. I find that's enough.

Some people will always prefer vi, but acme could be a gateway drug for many others. You can use it like Notepad, but there's a lot of magic hidden a mouse click away.

While all the hard-core programmers and coders around me use vim all the time they ridicule me for using nano.

I'm an admin not a coder, so I usually just edit conf files and firewall rules. I do spend all day at the cli and do write scripts as needed but I haven't found the need to learn vim.

Use what works best for you.

This helped me with the basics - http://www.openvim.com/tutorial.html

it's an online interactive "try vim" kind of tutorial

I wonder if there are more things like this

If you are using a UNIX-y OS, you most likely already have vim and vimtutor. If yes, that site is worthless.

I think some of us die hards push the pure vim way too hard. For example, while in insert mode

`end` is easier than `esc A` `ctrl+home` easier then `esc g g i` ...

Yehuda's advice isn't so bad. If the purpose is to be as efficient as possible, which is what I think most of us strive for, then why not use the extra keys? It took several weeks, actually months to become productive in Vim. Learning was a cycle of try Vim, get frustrated, go back to modeless editor until there is some down time, repeat. Vim bootcamp wasn't any fun.

It's sad to hear you had that initial experience. The person who got me into Vim recommended more or less what your friend did: start by getting a setup similar to my current editor, except with Pandora's Box just an Esc away. Then let curiosity run its course.

This is definitely what I recommend to people curious about Vim, and also what I recommend to people curious about functional programming. Saying "Here, start with Category Theory" is a great way to get a purely imperative programmer to stay that way.

Strangely perhaps I first used FINE (FINE is not EMACS) but there was this cool game called rogue [1] and rogue used the hjlk (and HJLK) keys to move around the maze. Playing for hours trained my fingers, and when I opened up vi for the first time someone said "Oh, just move around like you do in rogue" and literally I just needed to think where I wanted the cursor to be and my fingers made that happen. Strange way to learn those keys but it worked quite well.

[1] Which you may know as 'hack' or 'nethack'

I can understand the utility of vim, but I've never understood the argument about being able to churn out code so much faster. Sure there are times when I'm head down hacking away like some movie, but so much of my time is spent thinking, reviewing, doing minor refactoring, and just plain looking at what I've written.

I've never had a time where I felt I didn't have enough time to write all the code, but I've had plenty of times where I've felt I didn't have enough time to fix all of it.

It's exactly the process I'm going through right now. Just finished a small project using vim and haven't installed any plugin so far. I already got the reflex to :w and such in others editors. I've read at a few places to learn one command at a time, and it seems better this way. Otherwise, you need cheatsheets and man pages to figure out how to do things, while it should actually be done intinctively.

I switched from emacs to vim because I've found that vim-in-a-terminal-window works better when I'm also using GUI editors. In particular, cut-and-pastes don't get screwed up by continuation characters like they do in emacs.

You can get by with a small subset of commands that are close to what you use in graphical editors. Anything you learn on top of that is gravy.

It's really nice to have the option of terminal or GUI, and the same editor across platforms.

Have you tried emacs -nw ? I use vim in terminal windows by default, but have been curious about how emacs's terminal mode compares.

I used to develop Java in emacs. I gave that up and moved to Eclipse but I still use emacs whenever I have a blob of unformatted text that I need to chop up and manipulate. It does that better than just about anything. One cool thing about emacs is it doesn't care if you have a 30000 character long line while most editors will choke badly on that.

Also, pretty sure this has been posted before, but http://web.archive.org/web/20070814184957/http://www.moolena... is a great collection of tips for making vim pay dividends.

I've been using vim for a few years and I still use the arrow keys; see no reason to ever stop doing so. Too many people treat their text editor of choice as a religion and see the need to prove their devotion by embracing every difference it contains.

see no reason to ever stop doing so.

Plausible reason: hands do not leave the home row, so you can type faster.

That said, I switch between letters and arrows depending on what I'm doing. Sometimes the arrows just seem more natural.

It's simple. TextMate 2 for your GUI editor and vim when you need to ssh into a remote box. All of my remote machines have rmate installed so it's TextMate 2 90% of the time unless I need to use NERDtree and that's where vim is handy.

So actually it isn't that they were wrong in general, it is that it is possible to get into vim incrementally and customize it to suit your needs.

My dirty little secret: I have been a vim user for over 15 years now and I still use the arrow keys. :)

Vim is an awesome editor. its not that hard to learn. i used the man pages to learn vim.

2010.

try 1988 :)

I remember that article. I'd be curious to know if he still uses Vim.

The key piece of advice you were missing is "Don't try to learn vim at work."

Let's say you delivered packages using a horse and buggy, and people started talking about this new fangled "automobile" thing. Sure, you could try to dive into it and use an automobile for your next delivery. And when you crash the thing and your delivery isn't made, you get pissed off and say "I'm never using an automobile again!"

Or.. you could keep using your horse and buggy at work, and start learning the automobile in your free time. Then, once you've mastered the automobile, start using it at work.

But I'd disagree with the advice of learning vim a little bit at a time. It may be necessary to do that if you're trying to learn vim at work, but most people will acquire bad habits that way and learn to use vim in a watered down way. You've now tied some reins to the steering wheel and are sitting on the automobile's roof, trying to reach in the window and whip the gas pedal.

I think you hit the nail right on the head here. It can be detrimental to try and learn vim (or emacs, for that matter) while trying to get stuff done, but it is necessary to immerse yourself, as it were.

For those who don't use vim, switch right now (unless you're at work.) If you want to be productive, you'll have to learn to love the home row.

As an aside, it might be worth it to learn a couple of emacs movement commands as well if you're using OS X, as you'll be able to navigate textboxes without leaving the home row as well!

Why bother? You're not going anywhere any faster, and the ancient automobile you're clanking along in takes just as much maintenance as the horse did.

For one, there are automobiles (vim) everywhere. I can't take the time to install a horse on every remote server I use.

Well, that makes sense. I can imagine that someone whose job involves ssh'ing into a lot of remote servers and doing configuration things to them might have very different needs than a typical software developer does.

If people want to use vim in a "watered down way" then let them, it's better than rejecting a great tool because they can't fulfill a critical work need

I'm not ordering anyone to do anything they don't want to do. I'm just throwing some advice out there.

I disagree. I tried to learn Vim a few times during university. It was fun, I was able to use it productively, but it didn't stick. Neither did Emacs.

I only got invested in Vim at work, where I actually had to use a text editor for a significant portion of my day (actually, ViEmu, at the time). For university work, I never used Vim for quite long enough for it to really sink in.

Sure, you lose most of your productivity for a few days when switching text editors. So, I guess you should not switch editors when time is at a premium and deadlines are piling up. But you certainly need to have a good amount of time where you use the software full time, if only to build those all-important habits.

By the way, this is how I learned Vim, Emacs, and (shockingly) touch typing. It worked well for me.

The biggest time sink in adopting vim in my experience isn't necessarily learning the editing mechanics but rather the temptation to customize everything and adding plugins or scripts to perform actions with fewer keystrokes.

But then, I've also head "If you have a pet project, don't make it your first project in a new language - you'll end up hating the project, and hating the language", so it's definitely a variable, and arguably much more related to people's learning styles.

Reply on news.ycombinator.com