The OP has a really "sane" take on things imho (yes, it's incredibly opinionated, but it's blog post featured on HN, not a SO question someone like you can close in minute :) - and I'm glad he bothered to write it, as I'd probably just send the link to it to any newbies asking me about "the magical vim" instead of bothering to tell them what I think) and he's right on one thing: vim will not increase the productivity of a new user. The actual productivity increase will only happen months later (basically too late to worth it), and it will not matter that much because 90% of the time spent coding is actually spent either:

(1) plainly writing code (no advanced editor functionality helps here, Notepad++ is basically good enough!),

(2) making simple edits to code (again, more editor functionality doesn't really help because 90% of the time spend editing code it actually spent thinking about what to edit, not actually pressing the keys)

(3) reading code,

(4) exploring codebases (the only thing helpful at this is a full featured IDE - it just takes too much work to turn vim in to something like this, and you'll just end up with something mostly matching Netbeans feature-wise, so you could just as well install Netbeans or something else better for your language/framework in 5min and spend 1h to really learn how to use it),

(5) debugging (again, the only thing that could, for some, including me, increase productivity, is a full-fledged graphical debugger).

...and if you need to improve that last 10%, then you are far from a beginner at anything, eg. you are not the person that vim tends to be recommended to nowadays.

And the OP also expressed why I like ST so much: "To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing." - at most (not all) things ST beautifully follows the "don't make me think" principle: eg. arbitrary multiple cursors (no other IDE or editor besides Notedpad++ has them yet, no matter how many users requested this for JetBrain IDEs for example), that just let you "edit without thinking", keeping the code in your working memory instead of the sequence of search and replace commands.

But all that said, I absolutely love vim's keybindings and modal editing concept, so I tend to enable vim keybindings or install a vim-emulator plugin on most IDEs and editors I end up using because it also spares you of having to commit the different shortcuts that every other IDE and editor uses to "muscle memory". I see vim like more like an uptional UI/X layer that should be addable to any decent editor or IDE to enable experts to improve their 10%. Fortunately Sublime text has such a "layer" so OP's post is kind of valid.

It is absolutely incorrect that you have to 'keep Vim in your head just as much as the code that you're editing' unless you have not learned Vim at all. The reason you don't (constantly) have to think in ST or notepad++ is because you have already learned that editing paradigm. Although, that editing paradigm IS more obtrusive than vim's. It's abundantly clear that you do NOT understand vim's keybindings and modal editing concept, if you constantly think about vim.

vim has code exploration tools integrated: they just have funny names like ctags, grep, cscope. If you want them. You can also just use separate tools for browsing vs. editing, with no obvious productivity loss.

The productivity impact of having the debugger in your editor process cannot be a big deal, and it's pretty weird to hear that this is essential right after you stress that notepad++ is good enough. Which one is it?

If the point is that you spend most of your time writing, editing and reading code and otherwise the only advantages are in heavy-duty tools not present in ST, then the implication isn't that it's "sane" to reject vim, the implication is that it doesn't make any difference what you use.

When we're talking about a text editor for programmers, I don't need it to be usable by somebody who doesn't grasp the domain to begin with. I'll gladly give up some UI sugar because in this context a modal interface is exactly what makes me so productive with it and partitions the complexity into composable chunks that are easily reasoned about.

Well, I do use vim, so I can't really hate it, can I? :) ...it's just the thing that some things should just be plain and simple imho, code editing should not be a "domain" in itself and one should rather learn unrelated new things than bother tweaking that last 10% ...it's just a matter of preference and take on life, some strive for "mastery" at something and work on that last 10% to get an edge, others don't bother to achieve "mastery" at one thing but prefer to explore more things and get that edge by "perspective shifting" or "thinking more outside the box". I bothered to learn vim out of "exploratory curiosity", because I found the concept of such an interface interesting. But though interesting, I don't consider it a good idea anymore - if you give people a tool to manage complexity, they will take advantage and add more of it, for very little benefit.

I guess I look at vim as less an interface that a user needs to become familiar with and more of a language that one learns to manipulate text. For example, I don't think the same design principles that go into maximizing conversions on a website necessarily apply to learning Russian. The tradeoffs are different, as is the payoff.

Emacs support for multiple cursors is also available: https://github.com/magnars/multiple-cursors.el

Or, when you have a nice set of lined up/indented declarations, it's trivial to just right-click+SHIFT and drag a cursor before every line and start typing.

Oh, you mean like this?

http://emacsrocks.com/e13.html

https://github.com/emacsmirror/multiple-cursors

What do you mean by "arbitrary multiple cursors"? Do you mean the thing that all Scintilla-using applications (which Notepad++ happen to be one of) have?

  " Use w!! to sudo save after file is already opened
  cmap w!! w !sudo tee % >/dev/null

C-a and C-e and a dozen of others are there, yes, but good luck if you think you can use M-%, M-h or whatever is the Emacs equivalent of Vim's text-objects and motions (which is what the parent was thinking about).

Vim is good at editing text, is extremely portable, and works great with a partner in crime like tmux.

I have used vim for 12+ years, and the complexity of his setup makes me a bit dizzy.

Sublime and Emacs are joys to extend versus Vim, that doesn't mean it can't be done, just that it is tough.

I agree with the author - I'd also recommend Sublime Text 2 - but vim fills a great niche - when you only have a telnet terminal, so it's always good to know the basics.

Right tool, right job, etc.

Dear God. We're talking about a text editor.

Later I've developed a wrist pain and got interested in ergonomics. One thing I've noticed was how badly the arrow keys are positioned and how "unhealthy" it is to use a mouse with a right hand (numpad shifts the position of a mouse too far right). And then I started thinking about minimising use of a mouse and arrow keys. This led to the rediscovering of vim.

It was surprisingly easy to learn and later surprisingly hard to use other editors.

I'm pretty sure as a teenager is the best time to learn such tools. :P

I started with gvim, then eventually got comfortable. I never felt like I had to cram down vim facts. I just took them as they came.

Vim is my text-editor of choice, but it took me a lot of time and effort to customise it to make it more suitable for writing prose.

E.g. the fact that it scrolls by logical lines rather than screen lines (note I that I said scrolls. I'm aware that you can navigate by screen lines by using gj and gk). The way this makes the text scroll by unpredictable amounts when you have paragraphs of text is pretty jarring. You can hack around that by getting the text to auto-format and break lines up into screen lines, but there's all sorts of niggles with that (and FWIW, it causes some of its own problems, such as making it harder to search for phrases, because words may no longer be separated by just spaces but also possibly linebreaks).

What else would you find missing for a writing workflow?

For me this is primarily my planning/diary file and the phd documents I'm writing.

    autocmd FileType text set textwidth=75
    
    autocmd FileType text set formatoptions+=a

    autocmd FileType text set formatoptions+=w

- formatoptions+=a: auto-format as you insert text, which means it will (basically) automatically insert a newline once you've typed 'textwidth' number of characters on your line. it will insert a newline while you are typing.

- formatoptions+=w: this isn't necessary, but it has an effect on the way the auto-formatting is done. i find the 'w' options more convenient. With 'w', a linebreak means a new paragraph, unless trailing whitespace at end of line. It means that the 'a' option doesn't auto join lines separated by a linebreak.

- if you're not familiar with Vim's autocmds, what they're doing in the above definitions is setting those options for any text files that are opened (and only text files).

I've also setup Taglist http://www.vim.org/scripts/script.php?script_id=273 so that it can show a listing of the markdown headings in my document.

[EDIT: added brief explanation of autocmds]

I have the same setup as you - vanilla vim, barely customized and the development pace is hardly any slower than when I use Visual Studio with all its auto-completion, deep syntax parsing, etc. I saw Jonathan Blow (of Braid) saying that auto-completion and better debugging support is a deal-breaks for him, but everyone`s work pattern is different and I`ve seen plenty of cases where people using vim accomplished far more and faster than those with fancy editors. Tools are important, but they are secondary.

I use plain vi[m] for several reasons but mainly because I used to visit customer sites all the time and have to use their environments. If I need to edit a whole bunch of files I needed to do it with what the customer has installed, and the bare minimum to rely on is plain old vi.

My .vimrc (if it even exists) contains:-

    set background=dark

Of course plain old vi has its limitations but I know what they are and have pretty good ways of doing anything else I need to do.

a) Never thought vim was that hard to learn (and I first learned it when I was a teenager and nobody helped me. I switched when someone on a MUD made fun of me for using pico.)

Yeah, I was rocking vi in high school, and I'm no genius, I had an ULTRIX vi reference card. The article's assertion that you have to read any books to use vim effectively is bullshit. As for the religion part, that usually comes in when someone tries to dictate what editor other people will use. I don't give a shit if someone on my project uses Eclipse or MSVS, just don't take my Emacs away.

Totally agree regarding b). I like to be able to jump on a random machine and NOT miss overcomplicated .*rc configuration. My .vimrc is 11 lines long, including 3 comment lines and to blank lines....

Sometime, Vim user tend to make their Vim into full-fledged IDE, like completion, file-browser, etc. That things I though, makes Vim user gone insane.

Seriously, Vim just for editing text, nothing more, nothing more.

When I started learning vim all I knew were the command modes and how to move around using hjkl. Slowly over time I added more commands.