The return of Vim
Vim for everything
I'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.






Comments
Jilles Van Gurp replied on Sat, 2012/03/31 - 5:15am
Both eclipse and intellij have plenty of support for dynamic languages that typically includes support for auto completion, refactoring, debugger integration, syntax validation (that one alone is worth using a proper IDE), automated help, templates, runtime integration, etc.
Winding back the clock a decade on tooling improvements may not be the best idea. There seems to be a lot of resistence in the dynamic languages world against things like refactoring, auto completion, etc. There seems to also be a tendency of creating lots of toy, throw away code that later needs to be rewritten in a proper language because their developers didn't know how to refactor their code, keep their code clean and declined to use tooling that could have helped them to do that.
People seem to think that a lot of things that are in fact supported and possible today, are impossible. Sure, your mile age may vary depending on what you use but there's a strange mix of cowboy mentality, ignorance and arrogance there. A big reason for many languages having poor IDE support is simply that the people behind those languages are not engaged enough to bring their tooling into this milennium and not because of inherent technical limitations. People seem to think you are done after you hacked together an interpreter or compiler. Any second year computer science student can do that. Building good tools is a different matter though.
Anyway, there are several good stand alone python IDEs out there as well as plugins for eclipse and intellij. Ruby has great support in IntelliJ, Netbeans, and Eclipse. Emacs has a lot of add ons for all sorts of language. Scala IDE support is pretty decent as well depending on which IDE you use. Most people I know that use scala seem to prefer intellij right now but apparently eclipse support is catching up fast. Using primitive tools like vim is a choice, not a necessity.
And seriously, printing stuff and putting it on your desk?!? Why not use contextual help and save some trees? And why not use arrow keys. They're there for a reason: most keyboards have them and they have nice, easy to understand symbols on them and work with the minimum amount of key presses (i.e. 1). If you really are particular about your key bindings, most IDEs offer you plenty of choice there as well. Vim key bindings are a bit tricky because it is plain weird and awkward to implement but most IDEs support emacs key bindings at least. Speaking of which, the difference between emacs and vim (aside from weird key bindings for both), is that emacs has a long history of supporting loads of IDE like features. It had support for Java refactoring long before eclipse was around for example.
Giorgio Sironi replied on Thu, 2012/04/05 - 4:48am
in response to:
Jilles Van Gurp
Our problem with automated refactorings in dynamic languages is that part of the code is generated at runtime: while in languages like Java they would be safe, it's perfectly normal for us to write:
$this->$field = $value;
$this->$method();
which means that any attempt to automatically perform Push Up Field or even Rename Method may break the build...