
Vim's speed is not really the point (2013) - callum85
https://wrongsideofmemphis.wordpress.com/2013/03/27/vim-speed-is-not-really-the-point/
======
bhz
I'm not going to read the article, and I'm not going to even say if I like VIM
or not. I have become completely bored with the discussions about the pros and
cons of VIM and other editors. My only hope is hundreds of years ago people
were having the same discussions about pens versus pencils, and they were
equally as bored with it as me. I only comment because I care enough about any
others out there, who may think they are all alone, who are as bored with this
topic as I am.

~~~
blt
I think the tool obsession blossoms with repetitive jobs. If you perform
essentially the same programming task over and over, you focus on finding the
most efficient way to do it. If your tasks are less repetitive, you probably
spend more time thinking than writing code, so you are not as concerned with
tool efficiency.

Car mechanics debate who makes the best 3/8" flex-head ratchet. Engine
designers don't. _[citation needed]_

Still, the flex-head ratchet was probably invented by someone who got
frustrated trying to turn a tricky bolt with a fixed-head ratchet. Discussing
the benefits/limitations of current tools is worthwhile.

However, when it comes to text editors, I see a lot more "X editor is amazing,
here's why" than I see "all editors are insufficient, here's how we should
make them better."

~~~
edgarvaldes
I am not sure about "the tool obsession blossoms with repetitive jobs". Maybe
my counter-example is very specific, but I think about painters (even on
digital mediums) and the obsession about their tools.

------
farresito
I personally am a fairly lazy person, so moving my hands away from the
keyboard all the time to reach the mouse is just too much, and I get tired
fairly fast. That's the main reason I use vim.

~~~
aggronn
Same, though I don't know if tired is the best word for me. For me, its just
like, whats the point? Being able to use a computer without having to move my
arms more than an inch or so is kind of...relaxing?

~~~
pyre
Maybe what you need is the AlphaGrip[1]!

[1] [http://allthingsergo.com/blog/wp-
content/uploads/2011/08/gri...](http://allthingsergo.com/blog/wp-
content/uploads/2011/08/grip-front-view1.jpg)

~~~
JackMorgan
I've got one, the mouse leaves a lot to be desired.

~~~
lfowles
An upgrade I've made to my Alphagrips (with the optical trackball) is to use
either a stainless steel ball or a teflon ball instead of the cheap plastic
trackball. Edit: Just remembered I also replaced the tiny balls holding the
trackball with teflon balls. I think the biggest improvement was just from
replacing the main trackball though, I rarely have to clean the sensor/rollers
anymore.

My biggest issue other than that is the behavior of Shift doesn't match other
keyboards :\ Can't shift click to select ranges of text.

~~~
JackMorgan
Where did you get them to ensure the right size? I'd be really interested. I
tried to mod mine with an IBM trackpoint, with no success.

~~~
lfowles
Ordered them from Mcmasters. I'll have to check exact dimensions later, but I
want to say they were 1" and 1/8"

~~~
lfowles
Extreme-Temperature Slippery PTFE Ball, 3/4" Diameter

316 Stainless Steel Precision Ball, 3/4" Diameter

Extreme-Temperature Slippery PTFE Ball, 1/8" Diameter

Hope that helps! I also tried the same stainless steel in 1/8", but that made
the trackball loud.

~~~
JackMorgan
Thanks!

------
a-dub
ahh yes, editor holy wars...

a) it has little to do with the tool itself (vim vs. whatever), it's about the
payoff from investing time in learning an editor or environment well. once you
know your tool well, friction drops substantially. if you take someone who
knows something like intellij well and put them next to someone who knows vim
well, it would probably be a wash in terms of who is hobbled most by the
shortcomings of their tool. if you know a tool well, you know where it excels
and where it sucks, and you have strategies for using it effectively.

b) to really know a tool well, a significant investment of time and effort
must be made. i prefer to spend my time and effort on projects, to be honest.

c) vim is a tool that can be taken anywhere and the rewards of learning it can
be paid back for years. corporate environment? usually already there or easy
to get due to it being open source. platform? you can get it for pretty much
any visual environment. language? if more than 10 people have written in it,
there's a syntax colorizer for vim. need to do some ops stuff? vi will be
there. hell, in a pinch, even busybox has a vi clone.

is it intrinsically better or worse? hard to say. but as far as i'm concerned,
vim is a worthwhile investment because of its portability, longevity and
constant adaption by a strong community to changing environments.

~~~
tomlu
> it has little to do with the tool itself (vim vs. whatever)

I don't know about that. I've been proficient in other editors too, but I
found that vim's modal editing mode confers unique advantages when it comes to
staying in flow.

But if compared to an IDE there are several flow-breaking things in vim that
just don't work as well out of the box (navigation, indexing, debugger
integration etc), so if that's your point then I agree.

Of course most major IDEs have some sort of vim emulator these days so you can
have your cake and eat it.

~~~
bcheung
It's curious that vim uses modes and it is actually one of the things I really
like about it. A lot of HCI talks about how modes are "evil" because the user
can get confused and what mode they are in. I do occasionally issue a command
from the wrong mode but I find that the time to correct is usually extremely
small and far outweighs having to create more cumbersome bindings that don't
have collisions in other modes.

------
Yetanfou
To me, the difference between using a command-driven tool and a graphical
interface is comparable to the difference between explaining a native speaker
how to get to the museum (straight-on for 200 m, second turn left, first turn
right after the park) and trying to do the same to someone who does not
understand any of the languages I speak by pointing, making walking movements
with my hands, mimicking left and right-hand turns and trying to find a way to
bring across the concept of a park by these means.

Yes, I had to learn German, English, Swedish and French before I could
converse with people using those languages. This took time, but it was well
worth the effort. It took time to learn (eg.) vi as well, but this too was
worth the effort. I can still point and click my way through a maze of menus
if I want by using a GUI-enabled version of vi or any other editor, but why
bother when I can just tell the thing what I want in a few keystrokes?

~~~
oldmanjay
I suppose you could use one of the thousands of GUI-based editors that also
have key shortcuts for their commands. I don't know which one you used that
required menu navigation to do everything you should name-and-shame so we know
to avoid it.

~~~
splawn
Unless you are talking about emacs and/or vi bindings, the key shortcuts you
are talking about are just barely scratching the surface.

------
chipotle_coyote
While this is going to seem (and probably is) a bit inflammatory, I don't
think any article will ever make a convincing _Why Editor X Is Better_
argument for people who already use Editor Y.

In practice, there's a functionality bar for editors to clear; the likelihood
that you're going to gain massive productivity improvements by switching
between editors that are both past that bar is honestly pretty low. And that
bar is likely lower than most people think. Reasonable syntax highlighting,
good regex support in search/replace, _some_ kind of "project" support, _some_
kind of scriptability, and an ability to set basic editor configuration
variables on a per language basis (e,g., 2-space tabs for YAML, 4-space for
Python)... once you hit a certain point, then you get into progressively more
dubious arguments. "I can change the contents between these parentheses on
line 9 by simply typing '9Gf(ci(' while _you 're_ clicking in the line with
your mouse like an animal!" Good for you, ace, but you're not really saving
the time you think you are. (Also, you can perform a rough equivalent of
"select or delete the stuff between these parentheses" with a single command
in BBEdit, Sublime Text, and Emacs, and I'm sure in many other editors.)

I'm not suggesting all editors are absolutely fungible past a certain point --
there's solid reasons you may prefer one over the other -- but once you get
really good with a given editor, "modality is awesome" and "everything in my
editor is actually a Lisp command" shouldn't be particularly convincing
arguments. Generally speaking, you probably have better things to do with your
time than figure out how to replicate your favorite Editor X power moves in
Editor Y. Don't you?

~~~
obsurveyor
But can you repeat it in a slightly different place? That's where vim
typically beats other editors for me. Every editor can do a one-off in some
way. It's when you can repeat them in different contexts or quickly adapt them
to slightly different ones. vim gives you tools right up front to do this
quickly and accurately instead of doing repetitive mouse gestures or filling
out dialogs.

~~~
chipotle_coyote
I'm not sure that my interpretation of this is quite what you mean; most
editor operations I do day to day, at least, _aren 't_ particularly context-
sensitive. The balance command in BBEdit that I referred to above, for
instance, just selects whatever's in between the closest pair of braces,
brackets or parens, and if you keep hitting it, it expands the selection
outward. There's not much I can think of that _is_ context-sensitive other
than functions relating to the language you're editing, and I can't think of
any "class A" editors -- Vim, Emacs, Sublime, TextMate, BBEdit, etc. -- that
seem way below (or way above) the median in this regard.

The debate about mouse-vs.-keyboard will probably be argued long after
nobody's actually using either mice or keyboards. Personally I've found that
the farther you need to move the cursor the more likely it is that using a
pointing device for at least part of the operation will prove faster, and
AFAIK most studies done on this going back 30+ years corroborate that, but it
doesn't "feel" faster to us. (That's not directly relevant to editors, since
Vim and Emacs both support mice just fine, even if their diehard fans consider
that heretical.)

------
serve_yay
It takes too much thinking to use editors like that. I'm very much of the
"don't make me think" school, and I grew up using Notepad. Well, maybe I don't
use Notepad anymore, but I like it when I press the up-arrow key and my cursor
moves up a line. Simple.

~~~
mcbuilder
You're right it takes more thinking in order to learn vim or _any set of key
bindings_. Vim has taught me that you are able to "speak", by typing, a
language related to editing text. You are severely limiting your self in your
efficiency of editing if you choose to ignore your ability to define
macros/modes/whatever in a powerful text editor.

I use emacs now with a highly configured set of key bindings, and you're right
it's taken me a lot of time. You're comment makes me think there are two types
of programmers, those in the "don't make me think" school and those who spend
an insane amount of time in one of the big editors, i.e vim/emacs/sublime. To
make a gross example of the deficiencies of each, the "don't make me think"
school are the people who would manually enumerate function calls instead of
learning what a for loop is, while the crazy emacs hackers are the type to
spend more time fine-tuning their config than actually working.

------
shmerl
Some things feel unnatural about vim. For instance I always tend to remap its
default paste behavior to more commonly used one, and claims that one has to
"adjust muscular memory" don't sound convincing to me when it introduces a
drastic inconsistency.

Most editors paste text before the cursor position, and also set cursor
position after the pasted text (after pasting). Vim defaults are different. If
you press "p" it pastes after the cursor, and as well puts cursor on the last
character of the pasted text (not after!). Vim offers an option that's similar
to common behavior. It's "gP" (instead of "p"), so I usually remap p to act as
gP, since that's what I use all the time:

    
    
        noremap p gP
        noremap P gp
        noremap gp P
        noremap gP p
    

Another thing that's commonly different in vim, is that when you select text
in visual mode, it picks the character under cursor as well i.e. beyond the
highlighted area. Most editors only select it until the cursor, and not
including. Luckily this is also configurable with

    
    
        set selection=exclusive
    

May be in vim it was always the other way for historic reasons, but
consistency is convenient and at least in my case all other editors / text
forms that I use (including browsers) act differently from vim defaults in
regards to select / copy / paste behavior.

~~~
veddox
> claims that one has to "adjust muscular memory" don't sound convincing to me
> when it introduces a drastic inconsistency

Sorry, emacs user here... I just wanted to say that adjusting muscular memory
can go faster than you expect. I learnt how to use emacs a couple of months
ago, and have recently noticed the tendency to do ctrl-x + ctrl-s to save, or
ctrl-y to paste, even when not in emacs ;-) The latter can be a bit annoying,
but learning emacs was such a big plus that I don't mind much.

The article on vim sounds interesting, I tried and gave up learning it some
time back, I should definitely revisit it again.

~~~
shmerl
I don't mean you can't adjust muscular memory - you can. But when behavior is
inconsistent (like pasting I described above), you need to switch it each time
you use something that's not vim. For me it's not about what key combination
to press - that's not as hard to switch, but more about what behavior to
expect from the action "paste" and etc.

------
dozzie
Oh yes, this is why I find Vim much better than any other editor. Because I
don't need to think about editing, it just happens as I need and when I need.

------
jessaustin
As noted in TFA, was discussed here before:

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

------
bcheung
Some other helpful hints for the vim users:

1) You can use Ctrl-C instead of escape in most cases. This results in less
travel distance and avoiding the wrist rotation. Which leads to...

2) Bind Caps Lock to Ctrl like God intended it to be. That way you can use
Ctrl-C really easily and also the page navigation commands like Ctrl-(F|B|U|D)
are really easy. This one might not work if you have a caps lock key with
those weird notches.

3) Bind your Leader key to Space. I have the Unite plugin do fuzzy file /
buffer finding when I hit Space Space.

4) Set up your own custom key bindings to the other Ctrl keys are aren't used
by anything yet. Ctrl-S and Ctrl-V to split screens horizontally and
veritcally.

5) Bind Ctrl-(H|J|K|L) to move between screens.

------
antonpug
As a front end web developer, I am not really sure I understand any
"advantages" to VIM or VI, or any command-line based edit for that matter.
Sure, they might be great if you're doing scripting, messing around with the
back end, or dong DB stuff. But for me, writing day-to-day JS, HTML, CSS code,
VIM seems like a very huge burden. It's like trying to unscrew a screw with
scissors when you have a screwdriver laying next to you. Why not just use a
good, well-rounded editor like Sublime or Atom, or even Eclipse, for that
matter..? I often see web developer, dabbling in front end code, doing their
coding in VIM. Yuck. Someone explain?

~~~
rebootthesystem
No, you understand just fine. VIM has developed mostly irrational cult
following. It exists because it came from an era when computer keyboards were
not much more than typewriter keyboards. In that context you needed to get
creative in order to interact with any software. I was building and messing
with computers as far back as 1978, so yeah, I lived that era. And, yes, I too
wrote editors and programs that operated in similar fashion. The motivation
wasn't to make it more efficient or to keep your hands on the keyboard. The
mouse did not exist. All you had was a crippled keyboard.

I don't know anyone of my generation that doesn't simply laugh or look at the
cult of vim and isn't perplexed by some of what proponents of the cult say. We
ran as fast as we could from those kinds of interfaces once the computer
keyboard developed further and the GUI took to the world. The people who had
to use that shit 'cause there was no other choice dropped it like hot potatoes
as soon as they could.

Here's reality from the perspective of designing, building and programming all
sorts of computers for over 30 years:

If you are spending so much time typing that fractions of a second at the
keyboard make a significant impact on the development cycle, you are a hack
and don't know what you are doing.

Real software and hardware engineers spend far more time designing and
planning than coding. Coding is the end result of a process and, in terms of
time, is often dwarfed by design and debugging.

As an example, we are in the middle of a month-long process of designing a
database for a project. Not one line of code has been written. Every day is
devoted to database structure discussions and documentation. Once settled, the
DB code might take a week to write.

We are also designing an FPGA-based board as part of the same project. Over
three months have gone into research, circuit design and other tasks. The time
coding in Verilog won't even compare to the effort before getting to that
point.

And then there's debugging and the inevitable pivot or two.

There's nothing whatsoever an editor can do to impact this development cycle
in a measurable way. We use several GUI-based code editors. Nobody here is
saying "if I could only keep my hands on the keyboard for another few seconds
I could...". If they did, the laughter in the room would be so loud you could
measure it with a seismograph because it is so utterly ridiculous.

Do I use vim? Of course, only when I have no other choice.

~~~
wtetzner
> If you are spending so much time typing that fractions of a second at the
> keyboard make a significant impact on the development cycle, you are a hack
> and don't know what you are doing.

The win isn't that you saved fractions of a second. It's that your quick edit
was fast enough that it didn't interrupt your thought process.

> As an example, we are in the middle of a month-long process of designing a
> database for a project. Not one line of code has been written. Every day is
> devoted to database structure discussions and documentation. Once settled,
> the DB code might take a week to write.

You say this like trial-and-error isn't a valid way to design something. You
can spend as much time as you want designing things up front, but until you
try them, there's a good chance you won't know if it's a good design. You'll
always find issues later on.

Another way to look at it is this: you could write down you ideas on paper or
in diagrams, or you could write them down in code, and run them to see if they
make sense/work the way you think they should.

The code you write while designing doesn't have to be the same codebase as the
final product. It can just be a bunch of small programs you use to help
formulate your ideas.

~~~
rebootthesystem
Once you have enough experience you do far less trial and error. I rarely
write code that does not work. By that I mean, my code generally solves the
problem to be solved on the first write and is generally significantly bug-
free.

That's not because I am a genius or somehow super-human, I have a lot of
experience and have developed a decent process of design-before-coding. Trial
and error is really wasteful. It still has it's place in areas that might not
be entirely clear. Outside of that, design-before-coding can save tons of time
and aggravation.

In other words, coding is the end of a process, not the process.

~~~
wtetzner
Ah, I think the difference is that usually when I'm working on something, it's
a new problem, and I need some time to not only try to find a solution, but
first understand the problem. I find that trying to write a solution helps me
to get the problem space loaded into my head.

Different people have different processes, I suppose. And that's a probably a
big reason for why people have different opinions on tools: they have
different use cases.

~~~
rebootthesystem
Whatever works.

------
bcheung
A programming language / environment is at its best when it minimizes the
amount of cognitive load and context switches. Mouse movements require a
feedback loop where the user must lift their hand feel around for the mouse,
then move the mouse, then there is a rapid loop where the user moves the
mouse, sees where the cursor goes, determines how far from the destination it
is, then repeat until the goal is reached.

Vim cursor movements however are more logical and absolute. Go up 2 lines, end
of word, end of line, everything inside the quotes, etc. The cognitive load
required is much less in vim -- at least once learned, but definitely not in
the beginning when going through the learning curve.

It may not seem like much but every bit of brain power that can be freed up is
that much more brain power that can be used to concentrate on the task at
hand.

To someone who is trained in vim it just feels much more relaxed and fluid
when editing. To exaggerate, imagine if every time you had to use the mouse,
you had to open a drawer, pull out the mouse, plug it in, perform your action,
then unplug it, then put it back into the desk. This is a contrived example
for sure but it gives an illustration of the subtle distraction and annoyance
many vim users feel when they have to use the mouse.

------
Animats
Oh, I thought this was going to be about how fast "vim" runs. "vim" has
performance good enough for looking at large text files such as logs in the
100MB range. Some editors will choke on that. Gedit on Linux blows up on
excessively long lines, which is embarrassing for 2015.

------
cletus
You can count me as one of those who simply don't like modal editors. Every
vi(m) user has had the experience of pasting something in while in command
mode or typing commands while in editing mode. It's disruptive and annoying
(IMHO). Obviously YMMV.

But take the poster's example of changing parameters. Let me tell you how I do
this in IntelliJ:

1\. Click anywhere between the parentheses; 2\. Press Ctrl+W (context-
sensitive selection) repeatedly until I have everything within the
parentheses; 3\. Type the new parameters.

Now some might object to the mouse use here. There is a belief that the
keyboard is faster, which seems to at least in part be an illusion [1].
Anyway, (1) can be replaced by any number of keyboard navigation techniques.
Incremental search tends to be my "go to".

The one big use case for vim/emacs for me is the ability to use them over SSH.
That's actually pretty huge but I won't use either all the time just for that.

At the end of the day vim (and emacs) are just text editors, which is fine,
but you see this limitation all the time. Regex based syntax highlighting will
have funny edge cases (emacs is a little different here I know).

An IDE is built to understand code constructs and concepts like the context-
sensitive selection I mentioned above. Being able to move a java file and have
it update all my imports and packages. Being able to auto import when I start
typing a class name. Code templates (eg type "iter" or "itar" in IntelliJ then
hit tab when you want to write a loop).

The amount of mental effort that seems to go into recreating an environment
you get for free with an IDE is mind-boggling to me. By this I mean the
constant tinkering with plugins and extensions.

Unfortunately many vim/emacs diehards use Eclipse as a strawman argument
against IDEs ("I once used Eclipse and it was slow thus IDEs suck") when
Eclipse is (IMHO) at best a medicore IDE with a lot of warts.

The other area where vim/emacs have survived is with the C/C++ family of
languages (Visual Studio notwithstanding for Windows users). That's because
tooling in this area has been pretty basic. I applaud Jetbrains' recent CLion
effort.

The problem here is that the C++ grammar is so incredibly complicated it makes
tooling difficult.

This is one reason why I appreciate the design goals of Go: simple grammar
leads to easier tooling and faster compilation.

[1]: [http://ux.stackexchange.com/questions/30682/are-there-any-
re...](http://ux.stackexchange.com/questions/30682/are-there-any-recent-
studies-of-the-keyboard-vs-mouse-issue)

~~~
imron
> Let me tell you how I do this in IntelliJ:

>1\. Click anywhere between the parentheses;

You lost me at step 1.

I know you mentioned 'some might object to the mouse use', but I would argue
that a large number of people who prefer modal editors like Vi(m) do so
because they can be driven completely by the keyboard and don't require you to
use the mouse - which is disruptive and annoying (IMHO), obviously YMMV.

P.S. I gave you an upvote and I'm not sure why people were downvoting you. You
presented clear and logical arguments for your opinion and even if I disagree
with them, I can still respect them.

~~~
griffordson
> I know you mentioned 'some might object to the mouse use', but I would argue
> that a large number of people who prefer modal editors like Vi(m) do so
> because they can be driven completely by the keyboard and don't require you
> to use the mouse - which is disruptive and annoying (IMHO), obviously YMMV.

For some of us annoying is the least of the problem. Using the mouse to edit
for more than an hour or two causes me crippling pain. Without Vim, or
something else that would allow me to avoid the mouse 100%, I'm not sure I'd
still be able to edit code at all.

Not every developer will develop RSI problems, but fewer would if they used a
mouseless workflow.

------
jamesrcole
The way I'd put the point of this article: Vim enables the user to more
directly translate their intentions into actions

------
taf2
vim is like the force. you think about what you want and it happens.

------
ramgorur
I think vim's real point is its crazy visual block mode --

[http://vimcasts.org/episodes/selecting-columns-with-
visual-b...](http://vimcasts.org/episodes/selecting-columns-with-visual-block-
mode/)

------
bcheung
When I first learned vim, it took me a week to get to the same proficiency of
MS notepad. After that it just got better. Now it's my main editor.

------
return0
I have no idea how fast vim itself is. I know that i'm faster when i use vim ,
so i use it all the time, because time is the most precious thing.

------
Shorel
From my experience the argument applies just as well to SublimeText.

But yes, you need to know your shortcuts.

------
nichochar
That was a good read :) I love vim it's beautiful

