A few developers I've known have made the case that they just don't see text editing speed as the bottleneck in their day-to-day work. They're perfectly happy with the speed at which they can edit text and that's fine. What gets to me a bit is the dismissive attitude this type of developer tends to take towards usage of Vim, as if using it makes me some sort of misguided autist.
The reason I think it matters is that there are a limited number of hours in the day. When I get home from work I have maybe three or four hours on a good day to make some progress on my own projects. If during that time I can save 10 minutes of holding down arrow keys and carefully maneouvring the mouse cursor around my code and so on, then in a week that's an extra hour or so of extra project time.
The time you can save with Vim can be significant, depending on the task. However what I think is far more valuable is that Vim doesn't get in the way; it doesn't impede the all-important "flow", and perhaps most importantly it stops you getting bored.
When your muscle memory develops to a certain point, using Vim becomes a subconscious thing. You don't have to think about how to copy all the text in between two quotes and paste it at the end of the document; there are already words in Vim's vocabulary for doing that, so you just do it. You don't need to build mental steps because it becomes completely natural, as easy as typing natural English; and just like in natural language, the more words you know well, the more likely you are to be able to use the right word at the right time, using language effectively.
Equally valuable: Vim takes the repetition out of everything. A technically versed creative mind is wasted on any repetitive task. You should never, ever have to do anything more than twice in development. You should be able to repeat and automate tasks and scarcely think about it. In Vim, this need is met by skilful use of . to repeat actions and q to record macros.
When you edit text optimally, you can concentrate on the task at hand, and the editor stays out of your way and does exactly what you need it to. You don't need to build the "subtask" of making your editor do what you want; you can just do it. I think that people who focus on the time Vim does or doesn't save you are missing the point.
> They're perfectly happy with the speed at which they can edit text and that's fine.
I think they miss the point. Speed editing with vim is not about how many lines you may produce in the day.
It's about the lag between the moment you think about what you want to write and the moment when it's written. Your editor should not be in the way, and that's what vim, when mastered, is all about : you simply don't think about it anymore.
It's for the same reason that vim tries to reduce hand movements, so you won't feel your editor in those extra displacements.
Recording macros correctly and quickly is an art. Text objects help immensely, since they can handle a lot of edge cases in different places across your code.
> It's about the lag between the moment you think about what you want to write and the moment when it's written.
I think this is it exactly. In particular, when people start trying to incorporate typing speed into their arguments, it's a sign that they really don't understand where the bottlenecks are.
Sadly every minute gained with vim/emacs/anything is another 10 minutes wasted arguing about it...
Disclaimer: I use vim because I just like it. The key to becoming more efficient in my opinion? Learning to type faster. Saves you all kinda trouble when you're posting to HN as well ;)
Very true. I think the key to efficiency is alway happiness. When you're happy with your environment, you most likely can work without worries or disturbances and are thus efficient.
So, use the tools that make you happy. Personally, I use Emacs and I love it. But I don't think that Emacs inherently makes me more efficient than, say Vim or Sublime Text. That said, you should use a tool with sufficient power so you are not limited by it. So no Notepad, sorry.
It's more than just time savings; remember in "Peopleware" how they said even a one minute interruption really meant 15+ minutes of getting back into flow? If your dev environment gets in your way every time you use it, it will be like trying to drive a stickshift if you don't know how. As was said in "Pragmatic Programmer", your editor should be an extension of your hand; if you're always having to reach for the mouse to do something, it's like a cache miss (another great analogy, from Steve Yegge's "Effective Emacs").
While this doesn't have a whole lot to do with a specific editor, I have to say that most "modern" IDE's I've ever seen suffer from too much mousing, and you can recreate their useful features in Emacs. I still love vi (and use it for quick sysadmin tasks), but there's a reason I have the Firemacs addon installed in Firefox.
As for IDEs and mousing: I hate when I have to reach for the mouse - I try to do as much as I can with keyboard short-cuts. I'm currently using Intellij IDEA for Java coding, and it is definitely possible to do a lot without the mouse. The big advantage is navigation. Most of the time for me is spent navigating the existing code, and there Intellij IDEA really shines compared to just a text editor.
The reason I like vim isn't so much about editing speed as reading speed. I spend a large amount of time in source code for projects where I only want to check or change some very minor things. Always being a keystroke away from jumping to anywhere in the code turns this from a boring, hellish ordeal, into an quick, exciting exploration of code. Vim also has the perk of being terminal, so it integrates seemlessly with my flow when want to use cmdline tools (also often). Being able to refactor large amounts of code quickly, and with minimal repatition is also fun.
Interestingly, despite my strong prefence for vim, and the fact that I spend most of my time in it, when I am actually writing new code, the only time I hit ESC (caps-lock) is to save.
> A few developers I've known have made the case that they just don't see text editing speed as the bottleneck in their day-to-day work.
Right, it's only a bottleneck if you use the wrong tool for the job. As much as I love vi for text editing, it is the wrong tool for HTML editing and for a growing number of other file types for which more specialized editors exist (e.g. Eclipse for Java).
I know that vi experts think they are very fast with vi but they are wrong: if you are using vi for anything but simple text files, you are not being as productive as you could be and you should really consider being more mentally flexible and use the right tool for the job instead of vi for every job.
Eclipse seems to be a program that consumes all available memory to turn its windows grey when you type into it. I'm not sure how you think it's suitable for Java programming.
(More seriously: Eclipse is not suited for text editing, but it is suited for dragging and dropping getters and setters. If that's what Java programming is to you, you can save a lot of time with Eclipse.)
> Eclipse seems to be a program that consumes all available memory to turn its windows grey when you type into it. I'm not sure how you think it's suitable for Java programming.
Considering that about half of the Java community uses it and is quite happy with it, did it occur to you that maybe, your experience with it was not representative?
That's about right. It's true that my experience with Java is not representative, but I'm still unclear what would happen if I did manage to get Eclipse working correctly. Emacs can organize imports, complete symbols, jump to definitions, and things like that. It can't refactor as intelligently as I imagine Eclipse can, but the one time I've needed to do a really big refactor I just did it manually with a Perl one-liner (I should have written a full script, in retrospect) and cleaned up the handful of mistakes when reviewing the diffs.
(That's generally how I feel about Eclipse. It will spend several hours analyzing your source code so it can do a perfect variable rename. But you can get 99.99% of the way there with "perl -pi -ne 's/int foo/int bar/g'" and fix the two cases it broke in seconds. I'd rather not write that and not do the fixup, but with so much cognitive load to make that automatic, it just isn't worth it. Why does refactoring Java require a complicated GUI application with more settings than the Space Shuttle?)
The one feature I really want is something that detects what problem I'm trying to solve and shows me the documentation for libraries that can help.
But really, I wish someone would write an article like "why I switched from vim to Eclipse", but I only ever see ones where the author does the opposite.
> But really, I wish someone would write an article like "why I switched from vim to Eclipse", but I only ever see ones where the author does the opposite.
You haven't looked very hard, most Eclipse users today came from emacs or vi. And are you seriously arguing that a search/replace is more effective than a refactoring performed automatically with guaranteed correctness?
You are being unreasonably and inexplicable biased against Eclipse (and IDE's in general), it's pretty baffling.
I think you're unreasonably interpreting this as an attack. Articles of the form "I switched to Vim/Emacs" show up reasonably regularly here and on programming related subreddits. I can't recall seeing a similar article touting the benefits of switching to Eclipse.
Similarly, a cursory google search of 'switched "from vim to eclipse"' doesn't reveal any articles of this form.
If you can point me to such an article, or write one, I'd be interested, but I think you have to agree that articles of the form IDE->vim/emacs are much more common than the reverse.
I'm not being biased against Eclipse, I'm just wondering if the productivity loss its crashing and lack of editing functionality inflict is less than the productivity gain from being 100% accurate at renaming variables.
I use Eclipse (now that I no longer have an IntelliJ license) for doing heavy-duty Java, but if I can get away with it, I prefer to do things in MacVim. Eclipse is just too clunky feeling when I want to do simple text editing tasks; it totally throws me out of my flow. That's why I'm on HN right now, as a matter of fact. So clearly, I am not an unbiased observer. That said: have you tried Pathogen/Vundle? Vim plugin management these days is light-years better than the equivalent Eclipse nightmare (I've given up on about half my Eclipse plugins as things constantly break).
Eclipse is bloated, granted, but if you think its strong point is "dragging and dropping getters and setters" then you haven't seriously tried it. I used to think IDEs didn't matter much for basic code editing, but had to change my opinion after using Eclipse and IntelliJ (my preference) for a while. Higher-level (as in -- with knowledge of the programming language) editing and refactoring can make a big difference to your editing experience. Tasks that were tedious become trivial and part of the normal flow. You actually find yourself writing code in a different way once you understand how easily you can manipulate blocks of code (rather than just blocks of text).
I've been stuck doing Java lately (grumble grumble). I love Vim, but occasionally, I just want an IDE to dull the Java boilerplate pain. I've been copy pasting sample snippets in to IntelliJ, auto-adding all the import statements, and then going back to do my main coding in Vim.
I have to close IntelliJ quickly, however, lest the Swing fonts BURN OUT MY RETNAS on my Linux box. How can anybody get any work done with font rendering that bad?!
Jetbrains are changing their platform to use native font rendering.
From their blog:
"default look and feel on Linux changed from GTK+ to Alloy IDEA – it uses system fonts and has a much better overall quality (worth to try for current users too)"
Most command-line junkie types actually use vim, not vi. vim is quite practical for editing an enormous variety of file types at breakneck speed, and this is coming from someone who used to exclusively use environments such as Eclipse.
No! No, no, no, no, no. The best programmers use whatever they use. You are making the same mistake as the guy you're replying to. There is no one best way. We need to get over this mentality as a community. I don't mean to pick on you, as this was clearly just an off-the-cuff comment, but this kind of dialogue is simply worthless. I agree that the grandparent poster seems pretty clueless about vim and its ilk, but an equal and opposite reaction that's just as subjective and baseless will get us nowhere.
No, only the programmers that you know. One thing that makes a programmer great is that they will always pick the best tool for the job, not the tool that they are used to.
The point here is not that Eclipse or XCode is better than vim, it's that no matter how productive you are writing Java or Objective C with vim, you will be more productive using Eclipse or XCode.
So I'm supposed to learn an HTML IDE, a JavaScript IDE, a PHP IDE, a Java IDE and a PL/SQL IDE? Oh, wait, and a Bash IDE, as well as some "simple" text editor for php.ini and other minor text file editing tasks?
A multiplicity of IDEs, each with somewhat different or even opposing techniques isn't really the answer either, I think.
There's a mental cost to each tool - small in the case of a hammer, a pliers, a screwdriver, a vicegrip, but much larger in the case of an IDE. IDEs with similar physical actions but different results have a much, much higher mental cost. Why do you suppose that "vim" people use "set -o vi" for bash command line editing?
Also, where's your "intuitive excuse"? You know, the one where someone is familiar with Windows at home, so we'll make them use Windows at the office because we don't have to retrain them? That sort of thing is more proof that multiple IDEs aren't the answer.
Possibly, but I doubt that that is ever the reason for choosing one over the other. These productivity claims only serve as rationalizations of choices already made.
I opine that we're more productive with our tools of choice because we chose them. And that's perfectly fine. We can claim that everyone else would be more productive if they used our unique cocktail of tools and techniques, but the irreducible fact that they do not want to is proof enough of our error.
I recently had to start working in a java project, forcing a change from vim to a IDE. Most of the time I'm just as produtive as I am normally with vim (in other languages, java's verbosity is why I went for eclipse). Their have however been several times where I switched over to terminal for very specific reasons, generally involving grep.
I see the command line as the least common denominator for software, almost all of your computers functionality is available to you. It doesn't come up often, but when it does, it is definantly nice not having to leave just to edit text.
I've always prefered to retrain myself instead of using abbreviations because I was afraid I would need increasingly more of them because of the abbr crutch. However I have never heard of this happening to anyone. Does anyone have any experience with this?
Trivia: This is written by Bram Moolenaar, maintainer of Vim (the trivia part is that he maintains Vim; hopefully it's quite clear that it was written by a guy named Moolenaar).
The great thing about vi[m] is that even after twenty years of using it, as my primary editor for everything (paired with LaTeX for document generation, mutt for email, etc), and much of that time spent teaching students how to effectively use it, I still sometimes learn about useful commands that I didn't know about. (Today: asterisk to jump to next occurrence of current word.)
How much of this is because we still can't have a button which "puts the cursor where I'm looking".
(Or that we can't touch where the cursor should be).
"Go to the next instance of this word, wherever that is" is helpful; having to proxy a leap to somewhere you are looking at, through a vim command, still seems suboptimal.
The reason I think it matters is that there are a limited number of hours in the day. When I get home from work I have maybe three or four hours on a good day to make some progress on my own projects. If during that time I can save 10 minutes of holding down arrow keys and carefully maneouvring the mouse cursor around my code and so on, then in a week that's an extra hour or so of extra project time.