

Vim speed is not really the point - jaimebuelta
http://wrongsideofmemphis.com/2013/03/27/vim-speed-is-not-really-the-point/

======
dljsjr
I'm a huge vim fan myself, but I haven't thrown IDE's out of the window
entirely.

There are still 2 things that I can't give up that IDE's do better than vim
(in my opinion):

1\. Refactoring operations. I have yet to find a vim plugin that has the
extreme refactoring awareness I've become accustomed to in IntelliJ IDEA and
Eclipse. And writing a macro to do it for you is not the answer, because these
tasks are non trivial to do a.) correctly, b.) in the general case, and c.)
across an entire codebase. There's a reason people have sunk a gazillion years
and R&D dollars in to creating IDE's, and some bullshit vim macro that I put
together mid-day on a Thursday because I need to extract a method isn't going
to compete.

2\. Super-powerful auto completions. I get that vim has code completion
plugins, and most of them are _good_ (I'm currently using YouCompleteMe). But
they aren't _great_. IntelliJ has it's legendary "index the world" mentality,
and is really great at fuzzy match finding. Eclipse is a little clunkier, but
its ability to drop in the entire method signature and provide tab-stops for
quickly filling in the parameters is a boon.

The majority of my bias towards these features probably comes from the fact
that I write Java code for a living at my day job, where the "documentation"
is actually the code completion popup 90% of the time and most file operations
or refactors are accompanied by some degree of boilerplate that is handily
automated. Say what you will about verbose code and "enterprise" languages,
but learning an API as you go by mindlessly mashing Ctrl+Space and skipping
the inheritance/implementation rain dance is a huge productivity gain.

I do all of my C/C++, Haskell, HTML/CSS/JS, and Ruby in vim, where I have a
pain-stakingly customized pathogen setup that I sync across all of my
computers (personal and work). Code completion is good enough, between
YouCompleteMe and ctags, but I still miss refactoring something fierce. But if
FP Complete releases their Haskell IDE tomorrow and it isn't completely
offensive to look at (Leksah!), has good refactoring, and has good code
completion, I'd jump ship in a heartbeat.

I don't think that the whole IDE vs. vim/emacs war is real. I think that
they're two completely different tools that are good at very different things;
I will not argue that I am _way, way, way_ faster at just editing text in vim;
EasyMotion, ctags, never having to use a mouse... I love these things. But
anybody that writes off an IDE without fully understanding just how powerful
the two features I mentioned above can be when dealing with multi-million loc
codebases is being narrow minded.

~~~
TheEzEzz
Are there no good vim extensions for IntelliJ or Eclipse?

~~~
rooster8
There's a good one for IntelliJ called IdeaVim.

I tried solutions for Eclipse back when I used it, but I couldn't find one
that I liked.

~~~
dmiladinov
When I was using eclipse, I found VRapper[0] a decent enough vim plugin. I
also agree with you about IdeaVim, it's a good vim, and it's been open-
sourced[1].

[0]: <http://vrapper.sourceforge.net/home/>

[1]: <https://github.com/JetBrains/ideavim>

------
octo_t
This is definitely a good way to explain the appeal of vim, but this is
_exactly_ what IDEs let you do.

In intelliJ: oh I need to introduce a new parameter here, cmd-f6 -> add a new
parameter, set a default and it does it across the entire codebase.

Another key press and it runs all the tests again.

~~~
solutionyogi
Agreed. It's all about 'declarative' editing. I want to be able to declare my
action and let editor take care of the 'details'.

But, IntelliJ (or Resharper which I use) is only good for the language they
are written for. There are quite a few times where Resharper doesn't have what
I am looking to do OR I am working on language/text where there is no
Resharper or equivalent [especially for dynamic languages]. In such cases, Vim
is a god send. And the best part is that once you know the Vim language, it
can be used to edit any text (programming or non programming).

------
saosebastiao
So in other words: it is not the speed, it is the latency. I can agree with
that.

As an aside...I always sucked at the speed part. I have always been a 2, maybe
3 finger typer, throwing in a pinky for CTRL and a thumb for the space bar.
While my vimming is pretty fast, typing long segments is embarrassingly slow.
Have any of you overcome this after > 10 years of bad habits? How did you do
it?

~~~
goldfeld
You do realize there are actually courses in a technique called touch typing?
Fortunately, it won't clash with your bad habits. I can hunt and peck on
mobile keyboards yet my brain uses a whole different part of my memory to keep
my touch typing sharp and untainted from the lazy use of iOS' autocomplete,
never confusing the two.

~~~
saosebastiao
I don't have the problem with needing to watch my hands press the keys. It is
more that my hands hover needlessly high above the keyboard because the
fingers need to move more.

~~~
zargon
Typing with 3 fingers is not touch typing, even if you don't look at the keys.
Lean to touch type.

------
btipling
The real power of vim is its proven staying power. It is worth the investment
to learn it. It's been around for a long time and is likely to be around for
much longer. Newer, hip editors that depend on one person or small company to
make a living maintaining their product cannot provide such assurances. Some
have suggested open sourcing the application, but I am not sure that has
worked for Text-Mate 2.

Vim has been around, will be around, and is available pretty much every where
and has a giant community. That's the point.

~~~
zalew
you can replace vim with eclipse and all you said still stands valid.

~~~
ajanuary
To add some figures: * vi is 36 years old, vim is 21 years old * Eclipse is 12
years old

vim is on pretty much every linux box. Eclipse isn't.

~~~
zalew
it is on mine and it's all that counts. unless what you mean is that it
doesn't work without an X session on remote hosts, but in general I don't work
on live code.

'The real power of vim is its proven staying power' is a non-argument, today I
work on stuff that didn't even exist 10 years ago, there is no guarantee vim
will be even usable for the sort of work you will be doing in a decade, and
for sure there is no guarantee it will be the best choice. both vim and
eclipse are here to stay for the next years and both have a lot of support.

there are lots of reasons to learn/use vim, but a 10 years longer historical
consistency isn't one.

------
Roboprog
Sometimes, the IDE way of doing things seems to assume that your project is
one of the "lifetime employment" variety -- that this is the only project
and/or language you will ever work in the rest of your career, so you can take
an "infinite" amount of time and setup customizing operations to just that one
language and project, vs get in, hit hard, get out and move on.

------
laurent123456
> I was also forcing myself into improving my usage.

I can understand that people "force" themselves to go to the gym because there
are obvious benefits to it, but I keep wondering why developers "force"
themselves to use Vim. It's like playing and mastering a very hard videogame,
except it's not a game and it's not that much fun to learn.

~~~
danielbarla
I like to think there are obvious benefits to Vim, too. Why do developers
force themselves to touch-type? Because hopefully it will increase your
productivity, in the long run.

------
TheEzEzz
I rolled my own 'text editing version 2.0' with an eye toward both speed and
logical commands for ease of use (and to ease the mental demand).

At first I found that the speed and ease allowed me to code faster and longer.
Later I realized I was making mistakes more often, because of how little
thought I needed to put into editing. I think there is a fundamental limit to
how fast I can get ideas from my brain into code, and the limiting factor has
never been my input method. I still prefer working with an advanced input
system, but I now treat it the way the OP does: like a Samurai with his sword.
Sit back, relax, think, then strike. Afterward take a moment to read over what
just happened and make sure it is correct.

~~~
pekk
Is this a reason to do things awkwardly, that it is slower to do it awkwardly
forcing you to think more? If so, where does this reasoning stop? Should
editors intentionally make things awkward?

