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.
I've noticed that HN is particularly good among online forums about not squashing comments that go against tribal beliefs. Your first few comments, unlike this one, don't contain any justification whatsoever for your assertions. I don't downvote because somebody hates vim and it hurts my feelings. I downvote because somebody hates vim but doesn't feel like they need to justify why, they just want to say it.
Often people who have been downvoted assume that it's just because they've voiced a contrarian opinion, when in reality it's because they've made strong statements with no justification. Then they pretend like they don't care by accusing everyone else of hivemind mentality and proclaiming how much they don't care.
Now onto your argument. You say "programming is not factory work" and go on to say in many words that editing text is not the most important bottleneck in the way of programming efficiency. What surprises me here is that you think that this would somehow invalidate the use of an efficient text editor.
Nobody here is going to disagree with you that the thinking and the designing take more time than the actual typing of those ideas and designs into code. That's not the point. We're not suggesting that vim is solving your thinking problems, and just because vim makes text-editing faster doesn't mean that vim users naturally gravitate towards hacking out solutions without thinking. Nobody is counting keystrokes to measure their entire programming efficiency.
Vim is used for text-editing. Text-editing speed is not the core bottleneck for programming efficiency. You've stated this, but this fact does not at all justify your assertions that vim is a bad tool. Your response above is an attempt to minimize the act of text-editing, as if text-editing itself, rather than vim, is passé and unsophisticated. That is ridiculous. Programmers edit text files all the time, regardless of how smart and awesome their code generation tools are. Those tools don't reduce or obviate the need to edit text, they just provide better leverage; they increase the ratio of work done to the amount of text-editing.
My very first comment gave some (superficial) explanations. I didn't think that I needed to write a small term paper to voice an opinion.
As for down-voting on HN. There's plenty of evidence that it is badly broken. It's funny to watch the Apple fan-boys down-vote on emotion when you even peripherally chafe their idols. The emotion is evident from the fact that substantive posts are down-voted when nothing is materially wrong or offensive about them.
Most of it is also what I call chicken-shit down-voting. No explanation and no reason given. You are accusing me for voicing a contrarian opinion without sufficient explanation. What about down-voting without any explanation whatsoever? I have only down-voted a post once and I went out of my way to explain why I did so. I believe I owe this much to someone if I am going to exercise that right. And so, that is my policy: If I down-vote I have to take the time to explain why. Otherwise I don't do it.
It is clear that the HN culture --at least the one exhibited on this thread-- is that vi/vim are fantastic. So be it. I don't have time to screw around with this topic any more and fend off fan-boy attacks. I suspect the same is true of your case.
I have used a myriad of tools over the years. The only use I have for vi/vim is when I have no choice but to use them. I remember when keyboards didn't even have function keys. In those days these kinds of tools made sense. Today? No. Not any more. You don't have to see it my way. And that's OK.
> they increase the ratio of work done to the amount of text-editing
I would challenge you to quantify that in the context of a real project, concept to completion. I would be willing to wager that vi/vim don't contribute one iota towards the completion of the project.
I have yet to do a project where anyone even remotely said: Wow, that text editor saved us hours of work.
That aspect of the adoration of vi/vim is what I see as ridiculous. I simply don't think that any of it is materially significant to the timeline of any non-trivial project.
Then again, I really don't care to continue on this thread because it truly is a waste of time for all involved. So we are done.
Conclusions:
1- No contrarian opinion of vi/vim will be tolerated by HN vi/vim users.
2- vi/vim are fantastic.
3- Anyone even remotely thinking of suggesting otherwise just doesn't get it.
Trollish nonsense. You haven't even really read my comment, or you'd know that the leverage ratio I mentioned, which you're challenging me to justify, was actually about the efficiency of the tools you yourself were touting, not vim. Your "conclusions" are obviously trolling.
Trolling. Really?
This guy is expressing an equally valid argument. And one that I suspect a fair portion of HN readers agree with.
Personally, I thought it was April 1st when I saw a foot pedal for a text editor!?
Accusing him of trolling is really lowest-common-denominator fanboi bullshit. He makes valid arguments, agree to disagree and move on.
Yes, trolling. Really. In every sense of the word. He didn't even respond to my argument. It's whining about downvotes, about how he doesn't have time for this argument, more repetition of the same irrelevant text-editing-is-unimportant argument that I already responded to, followed by deliberately trolling conclusions. This is not a back-and-forth with points and counterpoints. This is me responding to his points, and him throwing the same shit back like a parrot. I call that trolling.
You think he has a valid argument, cwills? Maybe you can point out to me where he has actually responded to my points.
It should be obvious that it is intended to be useful and educational. No flaming. No trolling. No personal attacks. Just reproducible facts.
I am hoping that you will be one of the first people to post a recipe to that thread so that those of us who don't know enough about vi will, hopefully, see the light.
You've written hundreds, if not thousands, of words in response to this article (about a neat hardware hack lets remember. You've been on a tangent since square one...) accusing vi users of "being tribal" and "drinking cool aid", pounding your own chest, attacking the HN voting system, and in general just doing your damnedest to start yet another editor flamewar.
Then somebody suggests that you are acting trollish, and to you that is simply uncalled for.
As a follow-up to that. When I hire programmers I only care about how well they can reduce a problem to a viable game-plan and how clean and well-documented their code might be. I could not give a crap about whether or not they are 3% more efficient at pounding out keystrokes on a text editor. We waste far more time in other areas than in the mechanics of editing code. In other words, if editor efficiency is adequate and the programmer is really good at hitting the nail on the head, the editor is not a problem. As an optimization problem, the text editor is the wrong place to focus one's attention. It is far more important to create product that is well-written, well-documented (I hate code without comments), easy to maintain and extend.
If you are doing embedded work that involves systems that could cause harm to people or property it is far more important that a programmer understand how to write safe code and take the time to make sure it is safe than to optimize editing speed.
Nothing I have seen in my career justifies contorting ones' brain to learn the commands of a modem-era text editor. It's an utter waste of time when compared to optimizing what really matters.
Your first couple of paragraphs are spot on, but they in no way justify your assertions about vim.
Your last paragraph suggests that learning an editor like vim takes up enough time that it detracts from learning important software engineering principles. I'd like to suggest that learning vim, though scary at first, is not nearly as bad as all that. You pick up more and more of it as you go, and the accumulated bits of time saved over a long period more than make up for the time you spent getting over the learning curve.
"Modem-era"? I assume you don't use any "modem-era" command line interfaces, programming languages, APIs, protocols, or operating systems.
For the record, it's not that text editing 200% faster or whatever will make a significant difference in productivity. For me it's about removing one more impediment that gets me out of the state of flow. And I am more productive in that state. Some people use the Eclipse or Visual Studio shortcuts. I've learned the vim ones, because they're available on more platforms :)
As a side note, the foot pedals are a hilarious idea, but they will in no way improve productivity in vim. Just mentioning it because of your "my editor doesn't need a foot pedal" comments.
"modem-era" is entirely irrelevant. If you have a case to make, it has nothing to do with WHEN something was designed. And it is certainly possible to tweak the keybindings of vim if you need to, it is one of the key features.
If you do state machine code still, check out ragel: http://www.complang.org/ragel/ it's awesome. Since it compiles the state-machine for you, it is much more maintainable than ad-hoc approaches, and as an added bonus will generate state-graphs for you. I used to do the ad-hoc approach to (with an ugly-ass awk script) but since I found ragel, never again!
Would you like programming with a thumb keyboard instead of a full-sized keyboard? That is how I feel typing in a text editor without a vi-like setting. The absence of vi style editing feels unnecessarily crippling.
If you don't feel the same, then whatever; nobody is trying to force vi style editing on you. I don't see what your issue here is, why is it that you seem so intent on discrediting the experiences of others?
People are telling you that they find vi style editing to be beneficial or valuable for efficiency reasons, and you seem to me to be dismissing this. That is what I would call discrediting the experiencing of others.
jlgreco: vi/vim is an efficient text editor when you learn it! And even more efficient with a foot pedal! Don't discredit our time spent learning vi/vim when it is in fact an efficient text editor!
robomartin: vi/vim may be an efficient text editor, but in the grand scheme of a large(non-trivial) project, small improvements to text editing efficiency are irrelevant. Particularly at the sake or cost of learning and mastering vi/vim. There are easier-to-learn and more-intuitive text editors available now.
