Your first personal attack was subtle: "I understand that you like to click through your menus"
Now you resort to calling me a troll?
That's nice.
There's nothing unfriendly about a helicopter cockpit. Even if you've only played with flight simulators anyone half-way intelligent can probably figure out most of it within a few minutes. Flying one is a different deal, as mastering and understanding the complex relations between collective pitch, power, torques and aerodynamics. As a simple example, it isn't immediately obvious that flying in ground effect is different from flying above ground effect. Or the interaction between collective pitch, the tail rotor and the demand for power. This is quite different from understanding what the knobs and dials in the cockpit might do.
All of this from simply expressing a contrarian opinion on VIM.
HN does have an unfortunate trait: If you say anything contrary to "tribal" beliefs you get pounded and sometimes brutally downvoted. That does not mean that the tribal belief is right, it just means that there are enough tribe members to bully others into either not participating or simply adopting the tribal memes and falling into compliance. Well, that's not me. If I believe that someone is bullshit you are going to hear it.
Why do I believe that some of the hyper-keyboard-efficiency claims of VIM are bullshit? Because programming is not factory work.
If a programmer is spending so much time at the keyboard that counting keystrokes becomes important they are not doing a good job. I spend far less time programming than I do planning and deciding how to solve the problem. I don't just sit down and start hacking away without direction. By the time I actually fire-up a text editor or IDE to program I have state diagrams, database structures and algorithms pretty much selected and reasonably-well thought out. If I've done such a shitty job at the pre-programming work that my text editor's keystroke count actually matters, well, I'm a hack, not a programmer.
Some of the admittedly interesting things you can do with VI (http://stackoverflow.com/questions/1218390/what-is-your-most...) are, in my opinion, somewhat of a corner case. These are things that one might not do with great frequency. The fact that you can do them is interesting, but that isn't going to be a deal breaker if you only have to do them once every few weeks or months.
In some respects I can derive far greater efficiencies from using a tool such as Excel to sometimes cut hours of coding and formatting by using it intelligently to help generate code that is more maintainable.
One such example is to use it to generate state machine lookup table code that can be copied and pasted into a text editor instantly. I've done state machines with hundreds of states this way. If you do it right they are easy to maintaing and update. No text editor can improve on this level of efficiency.
Another very similar example is to use Excel to help generate JSON files from various tables and data. Easy to setup, maintain and modify. A simple copy and paste into an editor.
When justified, I have taken the time to create more complex tools that automatically generate complex code based on database inputs. One example that comes to mind was a tool to automatically generate all of the code to manage a menu system on an embedded device consisting of an LCD display and a few buttons. Every time the menu structure or content was changed it took days to update the menu processor code. The tool took a month to create. Once in place, almost anyone could generate the code for an arbitrarily complex menu system within minutes. No degree of text editor efficiency can solve these problems.
The point here is that, if I have to resort to counting keystrokes as a measure of programming efficiency then I have either reduced programming to factory work or I am so disorganized that I am spending a disproportionate amount of time typing crap that will have to be fixed many times over before it actually works.
To beat the state machine example to death. In my case it is very rare that I have any bugs when I code state machines, even complex ones. Granted, I've been doing it for a while in both hardware (FPGA's, Verilog) and software applications. Regardless of that fact, this is because I do all of the thinking and planning ahead of firing-up the editor. The resulting code, generally speaking, works on first run.
I've you've ever programmed a CNC machine manually (G-code) you understand this concept. You don't just stand there start hacking away. You take the time to plan it, do all the math, choose tools and verify the approach before you enter the code. If you don't, you'll learn the hard way. These machines are dangerous. I once made a programming error and had my Haas VF3-SS churn aluminum with a 3/4 inch roughing bit like it was butter. Amazing what something with that much power can do. I kept the fucked-up end-mill as a reminder of what not to do.
A professor of mine, who introduced me to APL, took every opportunity to drive a point home. He said that data representation is one of the most important tasks in solving a problem. If you represent the problem using a flawed model it can take ten times longer to create a solution. He pounded that into us to the point that it became instinct. That's why I will never touch a text editor unless I know where I am going. That's my context.
I also caution you and others when considering yourselves "experts" in any field. I learned a long time ago to never utter that word. One can be highly skilled in one particularly narrow area while being completely ignorant of other ideas. I certainly am. I am not just talking programming here. Having access to a larger context is sometimes very important. What makes sense in a myopic context might not make much sense when one is able to pull back to a different plane that covers other schools of thought. Be open minded.
Now, if it makes all of you really happy, down-vote away. It's always fun to watch the tribe in action.