I'd say that is heavily dependent on personal workflow and taskset.
Like Starcraft, the best thing the mouse is for is box selection. Everything else is done with keys.
My brain doesn't "point" at something in Vi motions, not matter how much I try. Maybe some people manage to rewire their brains, I haven't. Despite using Vi/Vim for a long time.
In emacs there's a mode called ace jumping. Essentially, it lets you pinpoint exactly on screen where you want to move the cursor ~3 keypresses.
Similar to how the vimium extension to Chrome let's you jump to any link/button/control with two keypresses.
These aren't motion commands as you'd typically get in vim/emacs; instead it's a different interface to allow directly jumping to an arbitrary position (more of a warp than a movement).
http://emacsrocks.com/e10.html
Anyways, the point I wanted to make is that even some instances where the mouse is considered superior can be negated by a different UX.
So consider the idea that FPS games are more effective with a mouse. I believe this is a UX choice to reward developing mouse skills, not a fundamental limitation of the keyboard. As such, consider the following levels of keyboard FPS controls--
Option 1: Aim by directional arrows. Will be beat out by a mouse user for sure.
Option 2: Aim by movement commands (e.g. B skips and tracks the target on the left, F skips and tracks the target on the right, etc). Might be on par? Definitely has a different learning curve than using a mouse.
Option 3: Aim by label. Every target has a letter hovering over its head, and pressing the key will aim & track at that target. I suspect this would be much more _efficient_ control scheme than using a mouse.
Option 1, is akin to navigating text with arrows, Option 2 is akin to navigating with jump commands, and Option 3 is akin to navigating with an ace-jump type interface.
So although #3 would be considered unfair in a typical FPS context, as a programmer I just want to reduce effort as much as possible.
Of course - in the context of an FPS, where the basic expectation is for it to be "skill-based".
But this makes the notion a truly great metaphor, IMHO: The goal behind a text editor is for the user to get stuff done. "Fairness" is not a constraint; everything is allowed.
I'd even go to say that if you've developed some AI that allows me to quickly do what I want without getting in my way, I'm in! I don't think this will be the case any soon (at least in a usable manner), but having it would certainly be great.
In fact, I already pondered if it might be doable to use the new, cheap eye tracking hardware one can buy nowadays (e.g. Tobii devices) to develop something like Ace jumping with...
Then there's also the ability of vim and emacs to quickly and precisely select text objects like words, paragraphs, functions, etc (even when they may span more than one screen). There's just no way a mouse can be anywhere near as fast as doing that for larger objects, and using the mouse is much more error-prone.
In addition my joints click when I reach for the mouse putting an actually physical barrier between keyboard and mouse movements for me personally, hence I tend not to move between the two a lot. Laptop touchpads doesn't induce this strain so those are easier.
Update with links:
https://github.com/guyht/vimari
https://addons.mozilla.org/sv-SE/firefox/addon/pentadactyl/?...
Software development has absolutely nothing to do with code entry speed.
Requirements gathering, mockups, design, testing, and thought make up the vast majority of development time. Then even once you get down to coding, you're often maintaining existing code rather than writing code from a blank slate, which requires more time reading and thought than actual modifications. A one character code change might take an hour; but you spent that time testing, following workflows, and documenting.
So the supposed developers online who obsess over their mechanical keyboards and 1ms time saved hotkeys really confuse me. I genuinely think the day to day software development that I and my colleagues do has no relationship to this bizarre online fetish with code entry speed.
If I really want to improve my coding performance, I'll do a standing meeting instead of a sit down meeting, reduce the number of people in a meeting, or stop requirements slip by completely clamping down on change requests mid-work. Those are my performance tips, and they save hours, not milliseconds...
On the other hand, I'm generally shocked when I meet programmers who don't know their tools at all, and in my experience that really does correspond to poor productivity. I'm not talking about people with average typing speed or people who use toolbar shortcuts rather than hotkeys, but programmers who don't know how to auto-format in their tool of choice or who stop typing every few keys to reach for the mouse, click file and then save. There's a mindset that goes with effective software development, and a natural curiosity and a constant desire to do things just a bit more efficiently are key factors in that mindset. People who are constantly getting out of the flow even in their editor of choice because they haven't learned to use the tool efficiently might not have the right mindset for software development.
But yeah, I recognize that the vim golf stuff is silly (but fun!).
I think this is false. I think, then I type. Then I think, then I type. The more time I spend entering code, the more I lose context on the problem. So while it's not as simple as "speed * time = total amount of code written", I'm fairly certain that code entry speed has a significant impact on my productivity.
Typing speed and use of shortcuts may not be the most important skills for a software developer, but I think it's borderline ludicrous to claim that they're irrelevant. For a trivial counterexample, try coding using an onscreen keyboard and mouse.
Again, the kind of software development people claim they do online, and what I see day to day have no connection to one another. If you're literally spending a whole day typing then you're extremely unusual. Even when writing fresh code with no front end, a lot of time is spent mapping data to structures, requirements building, diagramming, testing, or just considering the most maintainable way to solve the problem(s) presented.
These programming speed challenges that have popped up in the last few years are lies too. All these people do is pre-solve problems slowly and thoughtfully, then regurgitate those solutions within a very small timespan on the day. That's why many of them let the contestants create their own problem to solve, or give them very generic problems (e.g. twitter clone).
That's not the concept being argued for. The concept is that you aren't thinking while you type; you're dumping what you already thought of.
However, keyboard shortcuts can still be very useful for the tasks of testing and debugging. Consider the problem of stepping through many lines of code, or copy-pasting data from one place to another in order to run a test.
Lastly, when you know what you want to write (or refactor) it helps if the input system just fast enough that you can keep your sensation of flow. This part is probably highly variable among individuals.
Has Vim sped up the rate at which I can edit text? Probably, but for me this is missing the point.
I'm not a physiotherapist but being able to rest my forearms/wrists on the table 99% of the time when using Vim significantly reduces the risk of RSI.
I bet when you're in visual studio you hit F5 to debug instead of moving your mouse up and trying to hit the small button.
You probably also use Ctrl+<space> when need to pop up autocomplete directly, or Ctrl+r+r when you want to rename something quickly.
It's an idea known as 'death by a thousand small cuts'. Perhaps each individual build isn't significantly quicker using keyboard over mouse, but do it all day and it becomes significant.
This doesn't even start to consider the mental attention required for mouse usage vs keyboard usage. Every context shift potentially slows you down even more due to non-physical issues.
Trying to frame this as a discussion bout typing speed is just not accurate.
Neither one is optional. Also the actions undertaken by keyboard/mouse in Starcraft are generally not equivalent, e.g. you cannot select a hotkey group of units with a mouse, unless you select the same units visually where they are, which will always be slower. Same way you won't be making a selection box with a keyboard. Although possible, it is far less precise than a mouse.
In other words, there are certain subsets of actions for which the keyboard OR mouse will always be faster.
This is contrary to operating in a text editor or doing configuration in shell vs gui, where some people have a legitimate preference for doing it with a mouse vs text.
I think the main point was to say the aspects of the game that are faster with the keyboard is around 95+ percent and that top players reduce their use of the mouse to the bare minimum because of its inefficiency.
I think, however, if there are still micro mechanics (e.g. marine split vs banelings), then you will only be able to use the mouse to do that action - I have never heard of a professional player that uses the keyboard for microing units exclusively, but I do admit not having played in a while.
My larger point was that it's going to be hard to make proper comparisons because the result of the action has to be 100% equivalent. Otherwise, the comparison is pointless.
https://www.wired.com/2009/11/18-button-open-office-mouse-ma...
Also, didn't early mouse experiments involve rodents with many more buttons than the 2-3 that's common today?
I think software development also falls into this category. Some hotkeys are at least an order of magnitude faster. And 90% of the time hotkeys will be faster. But in some cases you absolutely need to use your mouse, it's just much faster.
Here's a YouTube video that discusses what it takes to be a competitive Starcraft player and shows them entering actions: https://youtu.be/zmYhX8fjmo8