4 ms·

So many people talk about learning vim, vim philosophy, getting proficient at vim, changing your workflow so that you can use vim better. You what this sounds l

by Tomis02 13y ago

So many people talk about learning vim, vim philosophy, getting proficient at vim, changing your workflow so that you can use vim better. You what this sounds like? A cult. Vim is a (surprise surprise) text editor, not a way of life. It's perfectly ok not knowing how to use vim and being put off by how awkward it feels. It's perfectly ok to use notepad++ or sublime text or whatever else you are comfortable with. To my knowledge nobody gets paid to use vim instead of some other editor; money comes from lines of code. It does not matter that you use vim, it does not make you a smarter person or better programmer (I should know, I often use vim at my work place). On the same note, it does not matter how cool you think you are when you manage to persuade git to do some complicated thing in a two liner command which could be achieved in svn or hg in two words, you are just being silly. Being proficient at vim/git when your job doesn't require it is like being able to rotate your left and right eyes simultaneuosly - one clockwise, the other counterclockwise. It's very funny/interesting, but utterly useless. Forcing yourself to learn vim for vim's sake or because you read on the internet how cool vim is and how 3l1t3 vim makes you is one of the things you'd be better off avoiding. Again, I should know. Seriously, don't drink the Kool-Aid.

Walkman 13y ago
You probably don't understand well enough how big a difference these tools can make in your efficiency. Of course number one priority is to know the technology, nobody argues that.
- 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.
tommorris 13y ago
I use Vim because I hate mice. I didn't know that I get free membership in the Church of Scientology base don my choice of text editor.
- Tomis02 13y ago
  You don't, but you get free membership in the Church of Emacs if you switch. http://www.emacswiki.org/emacs/ChurchOfEmacs http://www.emacswiki.org/emacs/ChurchOfEmacs

by Tomis02 13y ago

Walkman 13y ago

You probably don't understand well enough how big a difference these tools can make in your efficiency. Of course number one priority is to know the technology, nobody argues that.

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.

tommorris 13y ago

I use Vim because I hate mice. I didn't know that I get free membership in the Church of Scientology base don my choice of text editor.

Tomis02 13y ago
You don't, but you get free membership in the Church of Emacs if you switch. http://www.emacswiki.org/emacs/ChurchOfEmacs http://www.emacswiki.org/emacs/ChurchOfEmacs