First, Vim runs pretty much everywhere (vim for *nix, gVim for Windows, MacVim). The interface and commands are *consistent* between all of these locations. That means that whatever computer I'm logged into, I don't need to think about how to do something in the particular IDE that I'm using. Muscle memory takes over and I can focus on the content. Muscle memory does take practice to form, but it's worth it in any case and especially if switching environments is a necessity of what you're working on.
Vim's powerful commands and macros help me to edit text considerably faster I can when I only have the standard cut, copy, paste, and highlight commands available from the keyboard. Take a look at the explanation of how Vim evolved it's command syntax and the examples here (pardon some of the language). I'd explain some of the reasons, but why repeat information?
Vim is fast. It starts up almost instantaneously, especially when compared to larger IDEs with more functionality. It's commands and macros run quickly. This is another way in which Vim does not get in the way of my train of thought but allows me to continue working. When I've started up Eclipse in the past, I can go get a cup of coffee in the time it takes to start up. If I have to start it up or use any other functionality that takes a significant amount of time my train of thought will come to a screeching halt and it'll take a while to get back in the zone. (Yes, there are ways to get around these things, but that's not the point here)
Vim is open source, free, and extensible. That means that if something goes wrong with it, I can take a look under the hood myself and fix it (or write a plugin to do something I want to do). It also means there are many other users who are doing the same thing. Chances are that, if you're running into a problem, somebody else has too and might have found a solution. Additionally, I take pride in the fact that I've been able to help with a plugin, simple though the help might have been. I'd encourage you to pay with your time by contributing to vim itself or a plugin.
Are there cases in which Vim should NOT be used or in which it is not helpful?
Projects where IDEs are already used and the project setup files are static. It doesn't make sense to waste time trying to setup Vim to work with a project when all of it's settings (dependencies, paths, etc) are already setup in an IDE. However, as mentioned above, there are plugins that can be used with the IDEs to allow keyboard shortcut muscle memory to still help your productivity. That being said some projects can be setup to use multiple types of builders. If that's the case, you might be able to set it up in a way that is conducive to using Vim.
Vim's commands and macros are powerful, but they only help when I know exactly what I need to edit. It does NOT help me to determine what and how to edit the source code. Figuring out the what, why, and how is, of course, the hard part of software engineering.
While I can work on Vim itself or a plugin, it means that I'm paying for Vim with my time. Depending on what I'm working on at the time, this may or may not be worth it. There is certainly something to be said for paying for a product, being able to call somebody responsible for said product, and getting them to fix the problems you've got while you continue your work.
Debugging is an inevitable chore when working on a program. IDEs with integrated debuggers can make this job a lot easier. Here is a StackOverflow answer suggesting several plugins that can do the trick for C/C++ with Vim. However, not having tried them and being used to Visual Studio's debugger, I'm marking this under a negative (if you've got other suggestions for other languages, please let me know).
All in all, Vim has helped my productivity a lot. What are your thoughts?
No comments:
Post a Comment