5 ms·
I largely agree with the list, but I'd like to push back a little. Vim isn't everywhere, but it can be brought more places than many IDEs. So "Vim is everywhere
by actuallyalys 4y ago
I largely agree with the list, but I'd like to push back a little. Vim isn't everywhere, but it can be brought more places than many IDEs. So "Vim is everywhere" isn't a realistic expectation, but there is a similar advantage.
Similarly, the point about replicating IDEs is a little too sweeping. It depends on what IDE you're replacing, what features you want to replicate, and the quality of the plugins you're using. But it's absolutely right that, if you want a one-to-one replacement in terms of features and how integrated they are, I think you'll be disappointed. But if you're okay with fewer language-specific features that aren't integrated quite as tightly, you can have a good experience. I think the point about it not being tailored to your technology stack gets at the disadvantages of Vim better, actually.
The other thing I'd say about IDEs is that you can use them alongside Vim. For example, when I'm actively working on a Python project I frequently write code in Neovim, but switch to pudb for debugging and PyCharm for refactoring. To analyze data, I often write all the code in Jupyter Lab.
- behnamoh 4y agoI wish the state of Python was better in the Vim ecosystem, but I guess for data science work, Vim (or any terminal-based editor) will never be enough: - data science involves drawing lots of graphs. an IDE (e.g., VSCode) shows them inline w/o any problem, but terminal apps open new windows to show images... then you'd have to close them one by one... - I've had great success with VSCode when it came to symbolic computation using Sympy. I absolutely love that it can display rendered Latex equations inside VSCode. In terminal apps, that would probably open a new window. - terminal could have a limit on input characters. with GPT-3, for example, I've had difficulty pasting a long prompt in iTerm 2, whereas VSCode handles it w/o any issues. - I've assigned a shortcut to toggle VSCode just like a quake-mode terminal, and it's quite fast (if not even faster than iTerm 2 quake-mode). So I don't get the complaints about VSCode being slow. Sure, there's a second or two of startup time, but even a poorly configured Vim/Neovim with lots of plugins could get bloated and slow. - Something I really like about IDEs is that you can sync your config and have an exact replica of your IDE on another machine. This syncing happens on the cloud (e.g., using your Github account), whereas terminal-based apps need you to backup their dotfiles frequently and git clone them on every new machine. I do get the appeal of living in terminal, and I tried so hard to configure my Neovim to be usable for Python development and testing, but in the end, I had to switch back to VSCode. I do miss ranger, telescope, and undoTree extensions, but others such as vim.surround I was able to have in VSCode as well (using VSCode Neovim extension).
- actuallyalys 4y agoIf I used Python exclusively for data, I probably wouldn't use Neovim, either, unless I were developing a library that didn't require visualizations. I use Neovim for Python web apps and scripts.
- hakfoo 4y agoI learned vi because my CS200 instructor said "it's the only thing that's pretty much guaranteed to be everywhere". While VIM obviously adds a cacophony of bells and whistles, being able to handle the "skeleton" of vi-- modes and navigation and the core commands-- will be a lifesaver some day. On the other hand, I can recall trying to fix a machine so hosed once that vi wasn't available; I think I had to use ed to bootstrap the recovery process.
- johncoltrane 4y agoAuthor and occasional IDE user, here. I am _very_ familiar with both my editor and my stack. This allows me to use Vim for 9X% of my work because a) there is basically no friction, and b) most of my actual programming happens _outside_ of the editor anyway. For example, I don't use autocompletion and the manual completion that I uses is mainly about saving typing and avoiding typos. I use documentation for API discovery, not autocompletion. I trust my editor 100% for the low-level stuff but I rarely need the kind of handholding provided by IDEs. And, for the rare occasions when I do (hello Kotlin code base), well I use an IDE.