Hacker News Reader

Comment by swombat | Hacker News Reader

The difference is, if you just do it mechanically, you'll never get faster at it - the limit is the speed at which you can hit keys in a coordinated manner, which is not going to improve much over time. Something that takes you 100 keystrokes and a mouse movement today will still take you that much in a year's time.

However, if, with a minute of thinking through the correct incantation, you can turn that into 10 keystrokes and no mouse movement, next time it will probably only take you 40 seconds to remember how to do it. Then, 30 seconds. Then, 20 second. Then, 10 seconds. Soon enough, if you do it often, it'll become automatic. And then you'll have locked in a more than 10x gain in productivity which would have been impossible the dumb way.

This is also the reason we spend years learning how to program instead of just copying and modifying bits by hand, by the way.

View on HN

I find that in vi the fastest method for me is usually a mechanical combination of visual mode/movement/yank/paste rather than figuring out in my head where the next "word" ends or how many times to repeat the command. I've never been good at that but I consider myself very fast in vim. It is rare that I have to repeat a command and then I usually use the macro recorder and repeat it a random amount of times until I get it right.

> [Optimization is often beneficial.]

Your point is indisputable. Fortunately, it's not inconsistent with my own:

>> [Optimization is sometimes harmful.]

Optimization pays the greatest dividends to tasks which:

(1) could be brief,

(2) but are quite long and

(3) frequently necessary.

As to vim: On (1), brevity, Vim is powerfully so.

On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.

On (3), frequency, this surely depends on the person and task. I rarely delete every third occurrence of x between the seventh and ninth y... but if I used vim, I would make a point to.

So, I would turn to vim if there were several meta-editing tasks I routinely performed, each requiring a large number of keystrokes, each of which vim could reduce.

And hey, maybe this is the case. I'd love to see a plugin that analyzed my editing style and made suggestions to make me more efficient.

But originally I was just noting that efficiency and optimization are messy.

> On (2), length, I don't recall any of my meta editing tasks involving "100 keystrokes and a mouse movement." Customizable shortcuts can trim down the outliers.

As a simple example of that, using a dumb text editor like notepad as the baseline, changing the same 10 characters on 10 consecutive lines will take at least 200 keystrokes (100 DELs, 100 times typing the same characters back in, plus the movement keys - about 9 to move down to the next row.

With a bit of thought, in notepad, you can reduce this a bit. use Ctrl-C and Ctrl-V to reduce the amount of typing - but you'll still need to either DEL or select the words to replace, in the same location on each line.

With a more modern text editor, you can select a rectangular area and replace the text within it. In vi, replacing those 10 strings on 10 consecutive lines will take (starting at the first character to replace, like Notepad, and assuming it's a single word inside separators):

Ctrl-V e 1 0 j c A_NEW_WORD

That's 16 keystroke instead of over 200, with no mouse movements.

This is something I do frequently enough that I didn't need to even think for a millisecond to bring to mind the keystrokes needed to do it.

Now, I'm not arguing your editing style isn't different - maybe you've never needed to do this - but I would argue that this is a fairly common programming text editing task.

Why do you have the same 10 characters on 10 consecutive lines? Sounds like that is probably a violation of DRY, at least it always has been when I encountered something like that. Also, if you are comparing vi(m) to something, please don't compare it to notepad. Every editor and IDE I have used in the past few years has rectangular selection. Commonly with alt+click and drag, or shift+alt+arrow keys.

There are lots of scenarios when this comes up:

- braindead configuaration files. - data files that need some massaging - commenting out code blocks in languages which need a prefix comment delimiter on each line (e.g. python's # or haskell's --) - any time you are doing a series of operations calling functions in a module or from a single class/object and the name changes (e.g. foo.x();, foo.y(); foo.z(); and so on);

OK, I can potentially see where vi(m)'s rectangluar selection would be good for editing config files and such, but I'm pretty sure all modern editors have rectangular selection anyway (notepad is not a modern editor). My IDE has the ability to rename a variable and to comment/uncomment a selection which solves your last two problems.

I wasn't defending vim over your editor, just answering the question of when there are valid times to do 10 lines of block change. 2 more that came up for me yesterday:

We changed the data format being sent over JSON now I needed to:

1) make a bunch of int declarations into float declarations, fortunately those tend to bunch up.

2) Change a bunch of getInt calls to getFloat calls, but those are also bunched up together.

In a dumb Editor:

  1. Ctrl-shift-Right to select (1 or 3)
  2. Ctrl-C copy (1 or 2)
  3. Ctrl-H Open replace dialog box (1 or 2)
  4. Ctrl-V Paste the old (1 or 2)
  5. Tab (1)
  6. A_NEW_WORD (10)
  7. Enter (1)
  8. Replace (1) x10 (or Tab + replaceAll == 2)
  9. Escape (1)
  -------------
  Total 27 or 32
  That >80% Better.

On an intelligent IDE:

  1. Right Click Key (1)
  2. R - to choose refactor (1)
  3. R - Rename (1)
  4. A_NEW_WORD (10)
  5. Enter (1)
  ----------------
  Total: 14

I still want to learn Vim, because I somehow find it 'artistic'. There is some inherent beauty in Vi that I would love to be a part of. Unfortunately, the learning curve is fairly steep and the fear of losing productivity for 2 weeks is too huge. I still use vi for small changes, but for coding I find eclipse a more useful tool.

There's another giant advantage to renaming in an IDE over a text editor: You can be sure not to clobber any other variable/method references.

Here's an example, I want to change the name of my MyClass.Execute() method to something more descriptive. In an IDE, I right click and rename and I'm done.

In vim or other plaintext editors this is practically impossible without manually inspecting each call-site. Is "foo.Execute()" a reference to MyClass.Execute() or YourOtherClass.Execute()? Without actually parsing the program it's tough to know.

I love using vim, and I'm getting better at it the more I use it, but this is one of the major productivity drains I encounter that an IDE does way better.

You forgot to take the conversion rate between clicks and keystrokes into account.

  c = (k.d.t.r) / 13333337

  Where:
    c = click
    k = keystroke
    d = distance in centimeters between the "J" key and mouse
    t = area to be clicked in pixels²
    r = screen resolution in pixels²

There are no clicks, the Right Click Key on keyboard is just too awesome! :)

> Ctrl-V e 1 0 j c A_NEW_WORD

Another approach is something like:

    *:.,+9s/<ctrl-r>//A_NEW_WORD

But alas, that's 21 keystrokes.

(I post this now because it was closer to my first thought on how to approach the problem, and wanted to write it out to see if it was shorter. It wasn't, but maybe it'll be useful to someone. I learned about <ctrl-r>/ (fills in a search and replace with the previously searched expression), while writing it.

While I agree with your initial arguments, that last sentence doesn't make a whole lot of sense.

Learning to program takes almost as long as learning to use vi (hah!). Many people learn to program to automate a simple, boring task. Many people learn to program better by automating more of those tasks, before they progress onto "full programs" that have more of a stand-alone nature.

Within those full programs, there are many times when we continue to have a choice between doing it the quick but dumb way, or taking a little more time and doing it the clever and reusable way.

Of course, sometimes this can be taken too far - see yak shaving - but there are many points, while learning to program and while programming, where we face the choice between "do it manually in half an hour" and "take two hours to program something that will do it in 3 seconds". The difference between a programmer and a non-programmer is, largely, that given this type of choice, the programmer will tend to pick the latter option.

Reply on news.ycombinator.com