4 ms·

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

by Tomis02 13y ago

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.

pjmlp 13y ago
Fully agree with you. I do know VI (there was no VIM when I learned it) and Emacs. Yet I prefer to live in the cozzy world of IDEs. Every time I read a story like this, it resembles a macho attitude of being able to develop software in a UNIX System V world environment, talk about time travel to the 70's.
tomlu 13y ago
When using Visual C++ I'd use ViEmu. Other IDEs have similar vim plugins of varying strength. To put things into perspective, in terms of productivity if given a choice between Visual Studio without ViEmu or just vim I'd pick Visual Studio. Fortunately I don't have to choose.
tommorris 13y ago
Part of speed of editing for me is low RAM usage. When I'm doing web development, I tend to have a few browsers open (at least Firefox and Chrome), running web servers and databases, or the same in a Vagrant-managed VM. 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.
- Tomis02 13y ago
  I understand where you're coming from and I concede that you might be more efficient with your current setup, but I disagree about the debugger. Pdb, gdb and any other command-line based *db-s are what people first started using a few thousand years before entering the stone age. I've used gdb extensively and I can tell you there's no substitute for a good IDE where you can see the code, variable values, stacks, threads and watches, all at the same time; it makes life so much easier. It can be done in the old fashion way but there's nothing to gain from it. On the other hand I haven't seen any good free Python IDE-s (like Visual C++ is for C++) and you are sometimes forced to use pdb for the lack of a better option (Python Tools for VS are decent but took me a lot of time to setup properly and I didn't like the workflow). That said, the lack of good tools doesn't mean the old ones are good, only that the language lacks good tools, mostly because people get used to the stone age tools. And sadly that is the case for a lot of programming languages.

by Tomis02 13y ago

pjmlp 13y ago

Fully agree with you. I do know VI (there was no VIM when I learned it) and Emacs. Yet I prefer to live in the cozzy world of IDEs. Every time I read a story like this, it resembles a macho attitude of being able to develop software in a UNIX System V world environment, talk about time travel to the 70's.

tomlu 13y ago

When using Visual C++ I'd use ViEmu. Other IDEs have similar vim plugins of varying strength. To put things into perspective, in terms of productivity if given a choice between Visual Studio without ViEmu or just vim I'd pick Visual Studio. Fortunately I don't have to choose.

tommorris 13y ago

Part of speed of editing for me is low RAM usage. When I'm doing web development, I tend to have a few browsers open (at least Firefox and Chrome), running web servers and databases, or the same in a Vagrant-managed VM. 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.

Tomis02 13y ago
I understand where you're coming from and I concede that you might be more efficient with your current setup, but I disagree about the debugger. Pdb, gdb and any other command-line based *db-s are what people first started using a few thousand years before entering the stone age. I've used gdb extensively and I can tell you there's no substitute for a good IDE where you can see the code, variable values, stacks, threads and watches, all at the same time; it makes life so much easier. It can be done in the old fashion way but there's nothing to gain from it. On the other hand I haven't seen any good free Python IDE-s (like Visual C++ is for C++) and you are sometimes forced to use pdb for the lack of a better option (Python Tools for VS are decent but took me a lot of time to setup properly and I didn't like the workflow). That said, the lack of good tools doesn't mean the old ones are good, only that the language lacks good tools, mostly because people get used to the stone age tools. And sadly that is the case for a lot of programming languages.