[WesleyJohnson]

I've never understood the sentiment that using a mouse is bad. I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in. So if writing programs is a deliberate and methodical process that - I'd argue it's also slow. Why then is there antithesis that mice slow you down and you need keyboard shortcuts to be faster and more productive?

Maybe I'm just an old-schooler?

[chipotle_coyote]

I suspect a lot more of it is perception than people imagine: keeping your hands on the keyboard all the time seems like it intuitively must be faster. Early research in human-computer interfaces suggests that this isn't actually the case, though. From 1989:

"We've done a cool $50 million of R&D on the Apple Human Interface. We discovered, among other things, two pertinent facts: (1) Test subjects consistently report that keyboarding is faster than mousing. (2) The stopwatch consistently proves mousing is faster than keyboarding."

http://www.asktog.com/TOI/toi06KeyboardVMouse1.html

It's very easy on HN to find the pro-keyboard arguments. The pro-mouse argument is, more or less, that the context switch that really costs you time isn't the one involving the mouse, but the one involving remembering and/or finding the keyboard shortcut or function key.

Vim and Emacs style movement commands are faster than the mouse in certain contexts, but I'm dubious that's universally true. "I want to jump to line 123" is easy, but what about "I want to move the cursor to the open brace character right there"? No matter how much of a seasoned pro you may be, you're going to have to think for a moment about how to do to that: "let me count the '{' characters between the current point and where I want it to be. Three, so '3/{<cr>'." The mouse may make you move your hand, but it doesn't make you have to stop and count.

(It's also worth remembering that while mouse selection may not be as rich as "select within brackets" type commands, nearly all editors do have basic semantic mouse selection: double-click and drag to select by word, triple-click and drag to select by line. This can be a lot faster than you might think.)

[mjw1007]

I wish people would stop citing that old AskTOG article.

The $50 million (in 1989) research figure sounds impressive, but they don't say how much of that was keyboard-vs-mouse research and the answer is quite likely "very little".

It seems that, like most UX research, they were testing how well novices manage rather than how well people do after weeks of experience (the latter is expensive to test!).

When you get to "It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function." it's clear that what they were looking at is a very very long way from how a typical Vim or Emacs user works.

I think the article _is_ interesting as evidence for the proposition "it's possible for people to believe that they're quicker with the keyboard when they're not". But it's nowhere near enough evidence to get as far as "we can dismiss people who believe they're quicker with the keyboard as mistaken".

[btschaegg]

This this this. Citing articles like this and completely ignoring the setup of the experiments is one of the major pet peves I have with discussions like this one.

You could certainly reproduce those results - if the only program you test them with is MS Wordpad. If you're doin surveys involving editors that have a thought-through keyboard interface and with people who are actually trained in it, the result would never even be in the same ballpark. What we're looking for is the skill ceiling, not the skill floor.

[mtdewcmu]

I don't understand what task the users were doing when the mouse was discovered to be faster. The keyboard and mouse are not generally interchangeable; the task will generally favor one or the other. I'm assuming that the users were doing something like manipulating a GUI that favored the mouse and was awkward with the keyboard. The purpose of the study was probably to convince people to buy Apple's new mouse-centric computers.

Here is what's annoying: having to frequently move back and forth between the keyboard and mouse. Having to glance down to find the mouse to do one thing and then back to keyboard starts to break one's train of thought.

[mjw1007]

As far as I remember, in the one study that got reported users were asked to select a number of words scattered through a document and make them bold.

[mtdewcmu]

Oh, I get it. There was probably no efficient way to move the cursor around with the keyboard. That might explain why users said the keyboard was faster. It was faster for them to push the right buttons. They might have found the mouse cumbersome. They probably thought of the mouse wasting their time.

Do people still consider the results of this study valid? A mouse in 1989 was nothing like a mouse now.

[to3m]

This is the sort of thing the mouse is actually rather good for. Though you're probably better using Ctrl+B to embolden than you are the toolbar or menu.

[mtdewcmu]

It sounds like roughly the best case for the mouse and roughly the worst case for the keyboard.

[JupiterMoon]

> Vim and Emacs style movement commands are faster than the mouse in certain contexts, but I'm dubious that's universally true. "I want to jump to line 123" is easy, but what about "I want to move the cursor to the open brace character right there"? No matter how much of a seasoned pro you may be, you're going to have to think for a moment about how to do to that: "let me count the '{' characters between the current point and where I want it to be. Three, so '3/{<cr>'." The mouse may make you move your hand, but it doesn't make you have to stop and count.

But vim doesn't make you count either... press "/{" and then repeat "n" until you land on the correct character. Also for selecting lines shift+V and jk{} etc will get me there with no counting. I've used vim for years and I never count I just use visual mode.

[chipotle_coyote]

I'm not positive that's going to be faster in every than using the mouse, though, still. And selecting lines with a mouse is, in most editors, triple-click and drag. I'm not saying that's necessarily faster than using visual mode--just that, again, it's not necessarily slower. It seems to me that cognitively they're fairly similar, and it doesn't feel to me like using the keyboard is conclusively faster in this circumstance.

[JupiterMoon]

It comes down to personal preference and makes only minuscule differences in the grand scheme of a job that is mainly thinking not typing.

[lathiat]

The MacBook Pro setup is faster again because I can use the mouse with my thumb without getting off the keyboard (and the trackpad works very well). Even with the trackpad I use on my desktop I have to move my hands backs and forward.

[microcolonel]

Have you ever tried a trackpoint? It seems like it'd be right up your alley.

[lathiat]

Yeah I find it very hard to be precise with the trackpoint, it's probably possible but most of the time generally seemed to move too slow and then hard to zero in on the target.

Touchpads make it super easy to deal with acceleration better I found.

[chipotle_coyote]

While I'm not the person you're replying to, I always felt like I should have liked the trackpoint more than I did. I could never manage very precise movements with it -- and I learned that if you flail around with a pointing device, it's definitely slower than a keyboard, even if it's built into the keyboard. :)

[quicknir]

I use vim style bindings but agree that vimmers tend to exaggerate about the benefits. I think it works fine and so does a mouse and it's a small impact in the grand scheme.

However, with regards to your example, things like easy motion/avy solve this exact problem, I think no slower than a mouse. You basically punch in one, two, or more characters at the place you want to jump (depending which package/command you call), and then every match on the screen is highlighted and replaced with a different letter. Then you press that letter and jump there.

Not arguing that's it's much better, just that's approximately the same. Check it out: https://github.com/abo-abo/avy.

[chipotle_coyote]

I'd forgotten about easymotion -- I remember installing it years ago and taking it back out because it seemed so alien, but it's very clever, and I definitely believe that in practice it'd be fast, too.

[molloy]

> but what about "I want to move the cursor to the open brace character right there"?

Check out avy-goto-char! In my setup, `<SPC> j j {` and then one or two homerow keys would move the cursor there. And the rest of the avy functions are useful as well: https://github.com/abo-abo/avy/blob/master/README.md

There are other options too that can be situationally more efficient, but avy-goto-char is faster than reaching for your mouse (at least anecdotally) and you don't have to think about.

[chipotle_coyote]

Someone else mentioned avy above, too. I should definitely give it a look.

[mtdewcmu]

I think I avoid using the mouse with vim. It's not about the mouse per se, it's about having to frequently switch back and forth that becomes frustrating.

I think that you have not learned to move around efficiently in vim. I would never enter that curly-brace command. I think most of my moving is with w, which jumps one word at a time. I also use / to search and page up and down. It sounds like you may be using harder commands than I do.

Becoming efficient with vim takes a little effort and practice, and you seem to have not committed to one single editor. You can't expect to be very good at every editor at the same time.

[chipotle_coyote]

I appreciate the lesson, but that wasn't a curly brace command. What I said was typing "3/{", which seems like it's what you're suggesting: "/" to search for the "{" brace, but prefixed with "3" to jump to the third brace, which matches my example. You could do that with "/{" and two "n" keystrokes, but hey, that's one more keystroke.

I suppose I'm not a Vim superstar, but I've been using it since before the 6.0 release, and still use it today. You're right that it's not the only editor that I use, but it turns out that even if you can't be very good at every editor, when you've been using computers for nearly four decades you can be reasonably good at two or three.

[mtdewcmu]

My mistake. I would search for the brace and then press n twice.

[sdflkd]

https://github.com/easymotion/vim-easymotion

This plugin solves the curly brace issue. I find if there is something you find repeatedly annoying, there is probably a plugin to solve it. That or you suddenly have an interesting side project!

[hugodahl]

For me, the difference between keyboard shortcuts, and command line interface for that matter is that the same operation can be done semi-autonomously with the emphasis being on the variation (filename, path, flags, etc.) for the task at hand (no pun intended?). Performing the same operation with the mouse, there must be proper "setup" (get windows visible, or at least open to Alt/Cmd+Tab between them), and deliberate, visually tracked, hand/eye coordinated operations to perform the same operation.

For example, I can very quickly run a "full build" by pressing Shift+F6 and simultaneously turn my attention to the build output. Doing the same with the mouse, I would need to move the mouse pointer to the "Build" menu, after possibly spending a few seconds awkwardly looking for the pointer across multiple screens which vary in resolution/scale, click, move again down to the "Rebuild Solution" and click. Then at some later point in time, possibly have to reach out and move the mouse for the sole reason of getting the pointer out of the way of my field of view.

True anecdote: more than once, doing the operation the "GUI" way in the past, while trying to find the right windows, has truly derailed my train of thought as to what my next operation was to be.

Also, I may just be an old-schooler as well, cutting my teeth on command line OSes and network environments (Netware v3.11 anyone?)

[jmjanzen]

I think I can speak from a position of genuine dislike of mouse usage. I enjoy it for certain things, like perusing the web, or clicking through tickets while sipping on a morning coffee. The mouse is a great invention, and I would never want to get rid of it completely.

That said (subjectivity ahead), the mouse becomes annoying only when I'm done thinking, and it's time for doing. Imagine you've got your window manager set up just so, terminal multiplexer sessions all pointed in the right places; and finally, a problem -- and clear solution -- in mind. All that's left is implementation.

You start typing your solution, switching windows to compile or refresh a webpage every now and then. Things are coming together. As you proceed this way, a stroke of brilliance hits you, and you add an extra flourish that resolves an entire class of problems. Welcome to the "Flow State."

Finally, you realize you'll be needing a file from your Teamviewer session with another computer. You foreground that process, and navigate to the remote computer's file manager. So far, you haven't even had to traverse farther than three keys from the homerow.

Unfortunately, to transfer a file over Teamviewer, you'll need to use the mouse. You'll have to click three times to get to the file sharing widget, and use the mouse even more to get your remote/local directories lined up, another click elsewhere to initiate the transfer... close the little confirmation popup that's now obscuring your screen. It's not the end of the world, of course, but your dance has been interrupted.

I'm not sure you'll relate to anything I've stated above, and I'm by no means advocating "going mouseless" as objectively superior to your own preferred flow. Whatever works for you, works for you. I am hoping that my reply might help you get in the head of a keyboard jockey.

By the way, this reply was written with a rather fluffy cat sitting on my mousepad. So I'm not the only one to be inconvenienced when I have to switch to a mouse. Needless to say, George is a huge fan of vim. :)

[thameera]

Not just you, keeping yourself in the flow is why many professionals prefer the keyboard to mouse. Note the word 'professionals', in contrast to a regular computer user browsing Facebook whose curiosity makes him want to easily click on anything that comes to the sight.

I might be a professional when I'm in the zone at the office, but will become a regular user browsing out of curiosity at night.

tldr: the efficiency of the keyboard is contextual.

[watwut]

Navigating code with mouse is much faster then with keyboard only. Things like ctrl+click to see function definition or mouse over to see function documention, variable value or its type. Double click the name before I press shout cut for rename and so on and so forth.

[btschaegg]

Perhaps, if the only thing you're doing is actual navigation. As soon as you want to also edit said code, you loose said benefit since you're constantly switching between mouse and keyboard.

Als, if you do other actions than "goto definition", you'll also lose that speed very fast. In VS, "find occurrences" is burried somewhere in a rather convoluted context menu, while I can perform the according hotkey (C-k C-r) in a split second.

[watwut]

I either edit or navigate and switch between the two rarely enough. Obviously I don't type with keyboard.

In eclipse you right click the function and the "show callers" is right there. Along with keyboard shortcut so I have the chance to learn it. Along with all other options so I see them and can learn them too.

It is not as if keyboard shortcuts were mutually exclusive with using mouse - unless someone decided that one of these devices is below him. Majority of people uses both and switch between them fat.

[btschaegg]

> It is not as if keyboard shortcuts were mutually exclusive with using mouse

Of course, nobody said that. The mouse is one of the best user interface devices that has been designed for computing. Just not for working with text.

Now nobody condemns you if you like to use the mouse for browsing your code. However, if I'm right in reading your comment as rather snippy (hard to tell on the internet ;-) ), you seem to be very ready to do that to everyone seeing the merit in getting more proficient with their keyboard...

[bbarn]

I'm of a similar opinion. I grew up watching my mother have surgery on both of her wrists for what used to be called carpal-tunnel syndrome and now is just called repetitive strain injury. I've spent probably triple the time by 38 years old that she had in front of a computer, full time developing software, on a standard, non ergo keyboard which is nearly the same (even has clicky button switches!) as the one from her era.

But I've got a mouse too. I use it all the time. It breaks up the repetitive in RSI. I think this is a good thing. We're not all trying to break the record in Mavis Beacon anymore. Most developers agree productivity is not measured in lines of code and yet some seem to still insist that a few seconds at most to move their hands and use the mouse is hurting them somehow.

[btschaegg]

I don't think you can actually understand the issue if you haven't experienced it; that's just the way our brain works. I was extremely skeptical of Vim-bindings too, for example, and only learned them once I needed a powerful editor that compiles for ARM CPUs. While I don't use Vim anymore (mostly) I'd never want to go back in terms of the modal editing.

Imagine yourself working as a photographer using non-digital cameras. While you know exactly what you want a picture to look like, you can't tell how it actually looks without some major work (i.e. process your film). So, you have to a) take many pictures of the same motive and b) try again later if you're not statisfied.

Of course, you can get very proficent using analog cameras (a trained eye could e.g. certainly tell the proper aperture adjustments for a scene), but you'll have to train that rather inefficently, too. And sure, digital cameras have their drawbacks, but they have a very net positive effect on most photographer's work, that's why you almost find no one using the old methods anymore.

Now, you - as the "analogist" don't recognize all the factors that slow you down in your work. It has been that way for decades, right? It must be the proper way to do things. Now imagine I'm coming along, being used to use digital cameras and forced to use analog ones in your working environment. Can you imagine the frustration I'm going through?

I just want to make a picture of what I need and tell if it worked, if my last two seconds of activity will do. But the old thing has no screen I can use to see if the picture was to bright, to dark or even blurred. That's what the mouse-based workflow feels like after a while: It's unnecessairily slowing you down, constantly standing in your way. No matter if it's not the activity you spend most of your time with - it prevents you from going back to your real work as soon as possible. And if you're used to do the same things without it, you'll very likely get frustrated some time.

Edit: I just realized another good metaphor would be to compare old FORTRAN punch cards (punching them out, giving them to an operator and waiting until the next day for the results) vs. debugging a modern C# application. That'sessentially what you're doing with proper hotkeys: Tightening your feedback loop.

[btschaegg]

Funny thing, for me, this is exactly the reason why the mouse is annoying.

I use Vim-bindings pretty much anywhere privately (to the point of using qutebrowser and an awesomerc file that allows me to switch workspaces using hjkl), but am forced to use VisualStudio at work.

VsVim makes VS barely usable for me, but it still has so many usecases that are mouse-mandatory that I'm constantly cringing. When programming is mostly thinking, I want to spend my time doing that and not slowly pushing a pointer along on the screen. The whole dialog-based systems basically constantly interrupt my thinking flow, and context switches aren't free :-)

[atnnn]

Using a mouse is distracting. It steals our focus away.

Programming can seem like a slow process because the bulk of the process happens in our minds. Keeping our focus on our precious mental models makes us more productive.

Keyboard shortcuts become mechanical. When we're in the middle of editing code, whether we type "F8" "C-c C-l" or ":make", we can keep your focus where it belongs. But if we use a mouse to click on the "Build" button instead, we lose part of our focus looking for and aiming at the button. Menus and file explorers are especially bad at this: when opening a menu item or looking for a nested file, every single subfolder or submenu steals more of our focus away.

I know a few programmers who never use auto-completion for file names or methods. It surprised me and frustrated me a lot at first. Typing long file names without tab completion can be so. much. slower. But then I realised we can be much more efficient that way! Auto-completion interrupts our focus. We need to take in new information and make decisions. It's all about eliminating the step where we ask ourself "Why did I open this file?" or "What goes next?". It is easier to think about what arguments we want to pass to a method when we're not focused on selecting that method from a drop-down list. That is also why precise touch-typing is so important. We don't want to focus on either the pointer or the keyboard, we want to focus on our code.

The mouse itself isn't the problem, in fact some editors such as ACME or Blender make very good use of the mouse. The problem is inefficient UI design that interrupts our concentration.

[netzone]

See, for me it's the complete opposite, typing words unrelated to the actual code makes me lose part of my focus, whereas navigating the mouse or a dropdown list isn't requiring me to "create" words or strings in my mind.

Maybe that's just because I haven't gone through the learning curve, but I suspect the difference would be negligible.

[Edit] That's only for keybindings that force me to input string though, I vigorously use keybindings.

[throwaway91111]

I agree to some point; I don't think keyboard shortcuts are worth learning.

Unless it's part of your "inner loop" of productivity; investing there yields high yields in terms of translating thoughts to actions.

[m-j-fox]

Exactly. I used to be one of these hardcore guys typing fast and never taking my hands off the keyboard; then I got RSI and learned to appreciate value slow methodical approaches.

[ryandrake]

Interesting, I find I can type all day and not feel a thing in my wrists or hands, but just 15-30 minutes of continuous mouse usage, and I'm reaching for the pain medication. To me, staying able to use a computer without the mouse is about both speed and comfort.

[neivin]

This is a common problem in people who play computer games, especially those that are mouse heavy. The solution is pretty simple actually.

Simply lower your mouse sensitivity. Now you use your mouse by moving your entire arm instead of your wrist.

Watch how this guy uses his mouse: https://www.youtube.com/watch?v=X89152oocsA

Of course they do it to aim better, but it also puts less strain on your wrist and hand

[jasonkostempski]

In other words, you got old and slow. Happens to us all :)

[2muchcoffeeman]

This is one of the reasons I started learning vim bindings.

I can hunt and peck and still be relatively efficient at editing. So I can move my hands from the keyboard.

[noctuid]

It's not just that using the mouse is slow. The mouse is also dumb. By that I mean that you can't tell it to take intelligent actions like jump to/select/delete a particular semantic unit (e.g. a sentence). Using the keyboard allows for more intelligent actions and for composition of actions with (optionally) mnemonic keybindings. The mouse is far less precise and requires some UI for pretty much anything.

Besides, even if I'm thinking more than I'm coding that doesn't mean I'm okay with the coding part being slow.

[afterburner]

Just highlight the sentence really quickly. Do it enough and you get good at it. Just like with keyboard shortcuts.......

[mst]

I forget which program it is, but I've seen at least one document editor where one click places the cursor where you clicked, a second selects the sentence it's within, and a third expands the selection to the whole paragraph.

Combine that and modifier keys, and it's completely possible to have the mouse involved in intelligent actions, just not nearly as widely implemented as one might hope.

[lfowles]

How about firefox? I double click to select a word and triple click to select a paragraph.

[Mithaldu]

Personally i see it mostly as self-validation. I'm in an odd position in that i learned computing with an Amiga, meaning a computer that has a mouse, but was also still unadvanced enough to require lots of keyboard interaction. Nowadays i find that which i use depends a lot on the current context. Exploring things and browsing documentation particularly is done almost entirely with mouse and mouse gestures. Editing text is very keyboard-centric and the mouse only gets to act occasionally.

There's a balance there and it goes beyond even the task you're engaged in. I often find myself annoyed at the very same piece of software for providing too few keyboard shortcuts, or providing too few mouse interactions, depending on whether i'm working on something to the side, have one of my hands occupied, or just plain are having pain in one of my joints on that day.

People who proclaim one or the other as the alpha and omega seem to me stuck in a mindset that's strictly binary and refuses to see shades. (Granted, i am speaking with decades of entrainment. I can absolutely see how for a sysadmin in their 40s there may be little sense in trying to get comfortable with a mouse.)

[yissir]

I'm a keyboard-only developer with a very high key rate, but I don't write an above-average amount of code.

My keystrokes are used on a bunch of custom shortcuts that I use to quickly navigate and read code.

[Ace17]

> I see blog posts all the time about how a programmer's job is more thinking than writing code and/or writing good programs is also about taking out just as much code as you put in.

It becomes a lot more debatable when you're modifying existing code (rather than writing new code).

There are actually lots of cases when the thinking takes a small fraction of the typing, e.g "this block should be extracted as a separate method", "this class needs to be renamed", "this interface should be split" ... or, even more obvious "this file needs to be properly indented".

We have automatic tools for some of these operations, precisely because doing them manually might spend a ridiculous amount of programming time.

[janekm]

The discipline of thinking before typing is one that requires experience. I suspect that many young developers are stuck with not knowing what to type, and try to find solutions to their apparent lack of productivity (a guilt-free way of procrastinating).

I jest, mostly ;)

[tscs37]

I think it's one of these dogma that just get around by word-of-mouth.

Personally, I need the slight downtime of using a mouse when compiling a program, a short moment to pause and clear my head. Without a mouse I'd probably be less productive.

[un-devmox]

Ergonomically, IMO, using a mouse or track pad is much worse than typing. That said, I am a very deliberate and methodical developer.

[corecoder]

One important thing about keyboard is that it is a mostly uninterrupted buffered stream: with some notable exceptions, you can usually keep typing whether the previous command is done executing or not. You can type ahead several long running commands (in a shell, in an editor, for instance) and then let go. Or, you can click, wait, click, wait, click and then finally switch to something else.

Is it a big deal? I suppose it depends on how much you think in terms of whole sequences of commands.

[johnfn]

I don't understand this viewpoint.

The faster you finish the mechanical process of typing code, the faster you can get back to deliberation.

[koube]

To have some perspective from the other side, every time I try to use the keyboard I am immensely slowed because a large part of my brainpower goes towards remembering anti-intuitive keyboard commands. It reminds me of my short attempt to switch to a Dvorak keyboard layout.

The responses to your query make me think keyboard-only is rice.

[ChronosKey]

I think the idea is that there are times when using the keyboard is faster than using the mouse, whether it's using a certain editor or knowing the program's keyboard shortcuts. There's also the time taken to switch between using the keyboard and the mouse. It's kind of a micro-optimization.

[gkya]

The mouse is good for browsing and uncommon actions through drop down menus. There are about 30-40 keybindings I use in emacs, which are the most primitive or the most frequented commands. The rest I find through the drop down menu.

[tempodox]

There is no mouse in vim. You're a new-schooler.

[blunte]

An old-schooler would be the one asking, "why do I need a mouse?"

Anyway, it sounds like you're asking, "Why are keyboard shortcuts faster than moving a mouse to a location and then clicking [and potentially having to move to another location, such as the menu that just dropped down, and clicking again]?"

Does this really need an answer?

[ryandrake]

You forgot even more inefficiency: Lifting your hand off the keyboard and moving it to the mouse, [insert your above steps], then moving back to the home row.

[lorenzhs]

No problem at all if you use a TrackPoint. I don't even have a mouse, I use the ThinkPad USB keyboard at work which includes a TrackPoint. I know some people dislike them with a passion, and they don't look fashionable, but I can't use a keyboard without one any more.

[pix64]

Is scrolling through source code really faster line by line?

[blunte]

There are so many keyboard options for moving through source which you don't have with a mouse...

- Page up/down (and especially with home row shortcuts like in Emacs and Vi)

- Brace match jumps

- n line jumps up or down in Vim

- top/mid/bottom of view jumps

- page shifts up and down without moving the cursor

- top/bottom of file jumps

- jump directly to a line in a file

... and more

Seriously, put an Emacs or Vi power user next to a guy with an IDE and a mouse, and it's no contest.

[chousuke]

As a vim user, I don't really find myself needing to scroll "fast" ever. Instead, there are three common cases:

1) I'm reading through code, and scrolling one line at a time with j/k is fast enough.

2) I'm looking for a specific point in the code, in which case I use search to get to it.

3) I want to go to the bottom or the top of the file, in which case G/gg are much faster than scrolling.

Sometimes I might use Page up/page down to skim a file, but that's relatively rare.

[btschaegg]

Actually, this is also a point worth stressing for people without Vim-experience: Searching is a "first-class citizen" (as the FP-guys put it with functions).

It's only ever one to two keystrokes away. You press '/', enter your phrase, and press ENTER. Stepping is done with 'n' and 'N'. There really are no convoluted hotkeys for this - which means that you do it much more liberally once you're accustomed to it.

Also there's '*' and '#' to quickly find the next/previous positions of the word your cursor is currentl located on. The same thing applies there.

[noctuid]

That's what you do with a mouse though. With a keyboard, you can move by semantic units (like a paragraph or function), use fuzzy search to jump to a specific function, etc.

[ryandrake]

80j

Just scrolled down 80 lines

[blunte]

I didn't forget. I just didn't feel like enumerating what I think are obvious and commonly accepted facts :).

It really comes down to thought->muscle memory of keyboard shortcuts, especially those which don't require moving hands away from the home keys, vs the activity of reaching over, taking the mouse, driving it to a certain location on the screen, and then clicking. It should be obvious which will be faster.