The return of Vim
Vim for everythingI'm writing this article in Vim. This morning I have added the following to my .vimrc:
inoremap <Up> <NOP> inoremap <Down> <NOP> inoremap <Left> <NOP> inoremap <Right> <NOP>
noremap <Up> <NOP> noremap <Down> <NOP> noremap <Left> <NOP> noremap <Right> <NOP>
You may know these directives disable the arrow keys for moving around in a file (buffer, sorry), forcing the user to stick to (for the first times) to the HJKL keys in all modes, or to learn more efficient ways to move.
For example, in the first few minutes I have learned the usage of w and b to move forward and backwards between words; after another while, that e sends you to the end of the next word instead of the its start like the other two.
Abandoning the directional keys may be a trauma, but it's probably part of the Vim religion... However, while most of the conventions are oriented to keep you hands near the home row and avoid key combos, you should always reason about their goal. For example, remapping ; to : is a suggestion that should only be applied to US keyboard layouts.
(Programming) languages differences
Actually I don't think I would be very productive trying to write a non-trivial Java code without Eclipse or another IDE. The reason is that Java is a language that welcomes IDE.
It is verbose, so generating most of the code with an IDE saves time:
Map<String,MyValueObject> objects = new HashMap<String,MyValueObject>(); // plus the imports
All this can be generated from object = new HashMap<String,MyValueObject>();, even the imports. The same goes for checked exceptions and the mandatory try/catch or throws clauses.
Java is also statically typed, so it allows for safe automated refactoring: Extract Method and Extract Interface are only a click away as you can manipulate code at an higher-level of abstraction than the characters of a line. Unfortunately several refactorings like Extract Class often do not work how you want them to, and this results in code favoring private methods over new collaborators.
Generation and regeneration of code may be a problem: why check your imports and dependencies if with a click you can fix all of them (it's somewhat buried in Eclipse, but I remember a organize all imports commands.) What is useful during rename refactorings, may be a suppressed warning while moving classes around.
Take PHP or Ruby instead (or Scala, which actually is statically typed):
- they are concise: you do not need to generate coreograhy like field type definitions.
- For most dynamic languages, reliable automated refactorings aren't available anyway, so you perform them manually or use find and replace as the highest abstraction tool.
Even when Vim is not the choice, I see many PHP programmers choosing SublimeText or TexTMate, which are kins of Vim, not Eclipse and Netbeans. The inference IDEs can make on dynamic code for autocompletion and help is linked to the presence of docblocks in the comments of methods.
My only Vim tip
If you want to learn how to use Vim effectively, don't read piles of articles full of tips: there are already too many and a normal person isn't able to remember much from them (that's why I'm not sharing any Vim-fu move today).
The only way to learn Vim moves is to use it: I know two ways for pursuing this goal.
The first is printing: I print articles containing tips or cheatsheets, and keep them on my desk until I have assimilated the shortcuts. Old fashioned but fostering random acts of learning that build up over time.
The second is making exercises: vimtutor is essential for anyone starting out with Vim, as it teaches you commands for moving, copying and pasting that will stick with you forever. It's a very low-tech form of exercise, as it is just a copy of a template .txt document that you work on in a Vim session. Since vimtutor is really basic, there are also advanced versions oriented to an more expert audience.
I'm always skeptical about geek obsessions like learning every feature of an editor, or all git commands. However, the time spent improving our usage of an editor has a good Return On Investment; it's like money spent on a better keyboard.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)