|
In my experience, when working with anything but very small projects vim is a liability. Vim's main feature (speed of editing) is of marginal use when you only write about 10 LOC per day (as I would say is still the case 40 years after The Mythical Man Month was published, at least on average). The time when you're not writing code (which is most of the time) is used switching back and forth between files, going to declaration/definition, debugging,(auto)refactoring, changing between project configurations and so on. All this is very difficult to do with vim since it comes naked out of the box and you need to use all sorts of crutches to make is resemble a modern IDE. And when you switch another machine all you usually get is another barebones vim. For instance, when working on a C++ code base, vim will never come close to the ease of use of Visual C++. It might be better at "delete 2 lines starting at line #256", but that's about it. This can be improved by plugins that most of the time will not do exactly what you'd like them to do, so you will have to "adjust your workflow" to work around that. My original point was about using tools because it's cool or because the internet said so, and there's load of stories where people buy into how good vim is and then after a few months they still don't 'get it' so they are told they're doing it wrong (or just not smart enough). Ditto for git, lisp and other silver bullets. If you ask me, if efficiency were important people would be using hg instead of git most of the time because most of the things you can do in git you can do easier/simpler in hg - at least for the most usual cases. After a short intro to hg people will keep using it happily ever after, whereas the git user will keep coming back to StackOverflow questions to find out how to hard reset to head after rebasing from origin and rewinding. Speaking of SO, this quote matches my thoughts exactly: "It seems to me, that people using Mercurial are not so easily impressed. This is reflected in how each system do what Linus described as "the coolest merge EVER!". In Git you can merge with an unrelated repository by doing:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit Those commands look quite arcane to my eye. In Mercurial we do:
hg pull --force <project-to-union-merge>
hg merge
hg commit" I would like to read your insights related to efficiency. |
When you've got a browser or two and a Linux VM running, finding the extra 500Mb for an IDE can be rather taxing. I've tried IntelliJ, Eclipse and NetBeans. Always end up coming back to MacVim, saving a few hundred megs of RAM and not really getting any significant hit in productivity.
I was trying out PyCharm the other day (IntelliJ's Python IDE) and it was unable to keep up with my fingers. The text was lagging a I was typing it in. What was I getting from the IDE? Debugging? I know my way around pdb, haven't got time to work out how the IDE fucks that up. File navigation? I've got Ctrl-P. Changing between project configuration? Meh. Got Vagrant for that kind of thing anyway. That leaves autocomplete (can take it or leave it. Not bothered.) and refactoring (mostly I use Python and Ruby at work, so mostly it's a shit show anyway IDE or not).
Even on Scala projects, I've gone in thinking "IDEs are the answer" and ending up back in Vim after a few hours of flailing around trying to get the IDE to talk to the compiler.
Agreed on Mercurial though. I like Git, I like Mercurial. Both have upsides and downsides. More important is that we are finally moving away from centralised VCS.