Vim won't make you a more productive developer

Mac Siri on September 05, 2018

Disclaimer: I am playing devil’s advocate. I do believe Vim makes me more efficient with some trade-off, YMMV. We, as developers, spend a lot of... [Read Full]
markdown guide
 

Personally, I love Vim for the same reason that some people love raising a banzai tree, or building a toothpick castle. If I've got the time, I like to fiddle.

Sometimes, yes, I just want to knock some code out, or navigate around a big project to get a bird's eye view of everything. At that point, I reach for VS Code.

But, if I've got the time, or what I'm working on isn't super important, I like taking the time to tweak my .vimrc to get things just right. And then, in a couple of days or weeks, I do the next bunch of tweaking. It's fun and it's interesting.

It's relaxing to me to do something small and pointless, but to do it very carefully and to do it right. I don't know. Maybe it's a "when you focus on something small, all of the big stuff fades out for a while" thing.

I think that's the reason I'd recommend Vim to somebody. Not because it's "better than your current editor", not because you'll inherently "be more productive", but because you're interested in learning something new, adding another tool to your toolbelt, and fiddling. And I think that's enough reason to pick it up!

 

It's relaxing to me to do something small and pointless, but to do it very carefully and to do it right. I don't know. Maybe it's a "when you focus on something small, all of the big stuff fades out for a while" thing.

THIS. This so hard. I have NEVER been able to put it into words but oh man, this.

 

I think it's the same as dvorak and qwerty keyboards. One can type faster on dvorak, but there is a lot of time invested in learning and practicing. If one have time to invest in Vim, I don't see any reason why not.
I personally think that there is to much programming subjects to learn, that investing much time in text editor is pointless.

 
 

Totally agree. It's like knitting or oragami, but you end up with a cooler workflow each time, instead of a bunch of knick knacks laying around the house.

 

When the discussion comes to the point where it is "would you recommend Vim or not" I think of an analogy that I like to use: it's like recommending a bike over a car.

It might be an overly simplified analogy, and it goes together with the fact that I love my bike as much as I love vim, but it goes like this:

Vim is my bike, a car is an IDE, and your text/code is your distance. Short distance might be a script, a long distance might be a project.

With the bike you can get around. You choose short distances when you are starting, and you fall. A LOT. The better you get, the longer you ride. If you loved it, you'll love it more. If you didn't, then riding isn't your thing. You start tweaking your bike: did you choose a road bike over a mountain bike for your daily commute? that's fine, but ride. After you ride your custom bike, you don't want to use the same bike you used at the beginning. Your bike is yours and only yours. Then, you start using it for more than commuting. You ride it for fun, you do day trips, or even week trips. You use it in distances other rather go by car, but it doesn't matter, you enjoy it. And sure, you brag about it.

The car is something different. It's heavy duty. It comes with all the goodies you might need for long distances. You need to learn how to drive, sure. There are a couple of controls, you can go fast or slow, but as long as you don't get crazy you won't crash. You are surrounded by safety, sit back and strap on. Have a long distance to drive? it might come with a GPS, you just drive. (Sure, you can use a GPS with the bike, just as well as you can install an autocomplete plugin in Vim).

Some bikers can't wrap their head around people driving to starbucks and back. Some drivers are tired of the bikers bragging saying how biking is better than driving for "all the wrong reasons". Others, just choose the right transport for their commute. Sometimes you might want to ride, some other times you need to go across the country carrying a bunch of luggage, for which the car just works.

For me, it isn't about arriving, it is about enjoying the ride. Would I recommend vim? sure, why not? try it. Just know that, unlike when learning how to drive, you do fall from the bike.

 

Really well expressed!

I myself prefer nowadays PHPStorm for PHP development, but everything else is done in vim. The key point for me is how easy it is to script changes by recording macros and automating tedious refactorings. After all I already dug through 100k of ancient Perl code and could not have survived this without and editor that simply works.

What I most miss in these discussions is always the fact, that development environments are different. I would love to build all my software on one machine, locally and my bespoke editor config. But my reality is, that I have to analyze and debug my code on a couple thousand servers, where it simply is impractical to always have your config with you.

So my best tip for everyone: memorize the three most important settings (:syntax on, :set bg=dark and :colorscheme desert are these three for me) so you are neither blinded nor disgusted when moving systems quickly. And while the perfect setup might have vim-airline and zenburn, you can at least live on a remote system without going nuts.

 

Agreed. I believe that the title of the article is a bit misleading, as Vim can indeed make you more productive! if you choose if for the right task, and know your way around it. The more experienced you are, the broader range of tasks you can do productively.

The last part of your comment is also on point: if there are customization-elements that make your experience easier in a session on a remote/different machine then learning them will make your life easier. It can be even added to my analogy: if you get a bike while you visit someone else, what's the first thing you do? You set the settle to your height, probably change the gear, so that it feels comfortable. You can also drive without doing any of this, sure, but it will be a pain.

 

My stance on the general push for Vim - after having used it for years before moving back to modeless editors and although I maintain a semi-official Vim build for Windows - are the following considerations:

  1. Editor modes are annoying. In most cases, when I start my editor, I want to type stuff right away. Having to press extra keys for that is not something I'd want to have.
  2. The Vim ecosystem is broken. Four concurring plug-in managers - or was it five? - try to be the "only one".
  3. No Vim is like any other Vim. Because of a giant mess of optional features, :version is a mandatory command whenever I come across "a Vim".

Yes, Vim is cool. A version of vi is installed on most Unix and unixoid systems - but then again, so is ed. -- Vim imitates a concept that was made for systems which haven't been seen in three decades, but its preferences still make sense: everything is a mnemonic. A lot of that is purely emotional though. Impress your friends by not using a mouse, hoo! One could imagine higher aspirations. (My stance on syntax highlighting and code completion is a different topic... Vim's default colors hurt my eyes.)

I have learned a lot in my time with Vim. One of the things I have learned is that modal editors kill too much of my time.

 

I couldn't disagree more. Vim's modal nature is insanely convenient and fast, whereas non-modal editors force you to waste time mousing around in menus or GUI elements. Most programmers spend far more time editing and navigating code vs writing it.

"In most cases, when I start my editor, I want to type stuff right away." vim +star

I've used several plugin managers and never had any issue installing the plugins I wanted.

"No Vim is like any other Vim" is like complaining that nobody else organizes their kitchen exactly like you organize yours. 99% of the time, you'll be using the vim you installed and configured.

As for the original question here: a task being difficult and time-consuming isn't a good reason to avoid it, if the payoff is good. Learning vim is one of the best decisions I've ever made.

 

99% of the time, you'll be using the vim you installed and configured.

And since every single distributor compiles different options, you can never be sure about which they are.

If you can use git and GitHub, you can compile your own vim in easily less than 5 minutes.

That's true for all editors. (I compile from Mercurial though.)

 

To your first point: usually I edit already created files. In these files after I open them, very very rarely I am at the place where I want to start writing something. So I need to navigate to the place of my interest and vim-mode so far always bested other editors.

 

I like the idea of working solely on a keyboard, but I don't know if I'm convinced that Vim is the best solution. I've been working on a "regular" editors like Atom and VS Code ever since I started programming, and I haven't seen a need to move to something as hardcore as vim.

Also, the fact that it seems "hardcore" feels burdensome and heavy to me. Tools are supposed to help you be more productive, and while there's a learning curve to everything, I think it what you said is true:

it's kind of difficult for me to recommend it because it truly is a time-sink.

 

The one thing Vim does better than Atom and VS Code is performance. Even a GVim with a dozen of plug-ins feels snappy when compared to those.

But then again, so does every other non-JavaScript editor...

 

I disagree, it depends heavily on your plugins. I've had my vim slow to a crawl (full seconds between key presses and actions) because an environment variable wasn't set.

That isn't to say Electron based editors are fast either, they aren't. But VS Code is 'good enough' and has an insane number of plugins.

You can profile syntax highlighting by running :syntime on, moving around, then running :syntime report. Then fix it :)

The issue was actually caused by vim-powerline and some locale variables being not set. Not really the syntax highlighting, but thanks for the info :)

Great to hear. Personally I switched to lightline which is quite a bit leaner with respect to performance. I also removed git information from my statusline as I found that to sometimes cause a performance hit (although I didn't bother trying to fix it to update async).

 

Ehhhhh I would agree with this for most things save ruby.. specifically ERB files. I have super performance problems that I've never been able to solve, tried all kinds of stuff, but nothing I can think of works, Vim's fine with most things but Open an ERB file and vim begins to chug.

[deleted]

I was able to narrow it down with debugging, it only slows down in erb files, it's fine every where else. I believe it to be an issue with the regex for syntax highlighting.

If you think syntax highlighting is what's slowing it down, then you need to try to load one of the problematic files with vim -u NONE. That command tells vim not to load any config and thus vim launches in vi compatibility mode. If it it's still slow, then it's not the syntax highlighting and the problem is elsewhere. For example, vim doesn't take too kindly to files that are absurdly huge (>5MB) or have absurdly long lines (>10K columns). But the thing is, that in itself is way better than all the other text editors, which choke on files much smaller than the ones vim chokes on. You should isolate the problem before spreading something like this; you might be spreading misinformation.

 

Triggered!

I don't have a stance on the general push for vim since I don't believe it exists. Not sure I get what that means.

variety of flavors Vim comes in - Vim or NeoVim? GVim? again not sure what you mean.

you'll need to expand your code completion, syntax highlighting, and add additional functions like compilation - no actually you don't need to do that at all. You can if you want or you need that type of support. Personally in the teams I have been a part of and lead, reliance on IDEs can be taken too far to become a crutch and can inhibit understanding on what is going on in your codebase.

I have been doing development for over 20 years. I have used a lot of editors and IDEs over the years on a lot of platforms and I have settled on Vim as I like the feeling of it and I have the ability to optimise my workflow with it. Editing at the speed of thought is pretty close to the truth for me. It feels like playing an instrument, if you will, and similarly the more you do it, the better you get and the better it feels.

Vim is the fastest keyboard driven language for editing. It's not an IDE but you can add in IDE style features if you would like. There is a reason for there being Vim plugins for most IDEs including Emacs the best operating system without a decent editor. If you don't want to mess with configuring Vim much you don't have to. NeoVim out of the box has some pretty sensible defaults.

Have a watch of some of the destroyallsoftware.com screencasts to get a feel of what that looks like.

 

what about adding vim's keybinding in <your-favourite-editor>

 

Sure, if that works for you and maybe that can be a good softer introduction for some folks to Vim and modal editing in general.

 
 

I started out learning Vim because I had to regularly modify files on production systems that didn't have a IDE option installed. Now I use it because I'm comfortable with it and really like it's speed.

VimAwesome is a fantastic resource especially with the plugin/plugin manager issue. I've switched back and forth from a couple of different managers and haven't had any troubles.

I've tried most of the big name editors, each for a reasonable amount of time, and they're good. I always come back to Vim, though.

It's nice knowing that Vim will be on pretty much every system I log into. If it's not, it's usually no trouble to get it installed. It's fast and I think the movement keys are great. You can customize it as much as you want to and get some really great features.

 

I'm on the fence about this as well.

I think every developer should at some point install Vim, try out a bunch of plugins, and run through some tutorials — even if it's just so you won't feel scared when you end up within the editor by accident.

But more productive? Complex editing tricks often require a refresher in the form of a few internet searches and a bunch of experiments. You tell yourself that it's investment in future productivity... But obscure key combinations are long gone from my muscle memory when I need them again.

I love Vim as an editor, and use it out of habit when editing configs, markdown, latex, and bash scripts.

For larger code projects I personally prefer the Jetbrains IDEs, as they offer great out of the box smartness tuned to specific languages.

 

I am vim user and I have tries to switch to other editors and the main thing that makes me switch back is the lack of the leader key in vim mode for any other editor out there. I have my key strokes that "save me time" intiated by the leader key. I just cannot find an editor that will allow me to do that without being another time sink to setup.:-)

 

I got started with vi on Sparc 5s (and less!) in 1996 or so, and over the decades have accumulated a 200-line .vimrc file. I do not use it for every purpose, using VS Code for most of my coding, but I do use /vim?/ for a few special purposes.

  • Sorting - For things like the entries in CSS, I like them to be sorted, so that I don't have to hunt as hard to see if font-size is set. I'm sure it's available in Code, and I think I have it set for one of the systems I use, but it isn't built-in so it isn't consistent. I go into visual mode and get it done.
  • PerlTidy - Here, I'm very in the minority, but my code base and experience is largely in Perl. 1) the Perltidy VSCode extension isn't happy on on non-Linux systems. 2) the Perltidy VSCode wants to go with system Perl, not my self-compiled current Perl, and thus doesn't always work right.
  • Remote - The machine I'm editing on is not always the machine under my fingers, and the user I'm editing as is not always me. I can often mount those file systems and edit with VSCode, but it is often quicker and easier to just ssh in, vi file.conf and get out.

Honestly, I could easily get my .vimrc under 100 lines -- maybe less -- without losing any of the functionality I need. A lot of it is taken from people like Damian Conway's vim settings. See Damian Conway show off vim at OSCON.

My problem is the same as the users who don't use it often: it would take time to determine which things I use and need and which things I do not, and it is easier to just go forward with things as they are. I was strongly in a sink-or-swim environment when I learned vi, surrounded by lots of people with similar knowledge but knowing just that keystroke that I needed to move forward. But the space I work in is somewhat anachronistic in the coming cloud world.

I would gladly wear a t-shirt with the "Oh Ned! You Are a vi man after all!" image on it, but honestly, if I could trade my not-ready-for-git-or-other-revision-control current codebase for something where I wasn't developing in production (It existed like this before I got here) and all it would cost me is my vim knowledge, I would trade it in an instant.

 

In my experience the one thing that Vim got right was keybindings and mapping. Modal editing does take away many pains of editing and does make you faster.

However, where I found Vim severely lacking was basically other things like:

  • opening multiple files
  • opening multiple projects
  • syntax highlighting
  • and file navigation
  • fuzzy file search
  • tag search

My current setup consists of Sublime Text 3 with NeoVintageous for Vim like editing.

I believe it gives me the best of both worlds. Vim like keybinding and modal editing with all of Sublime's sublime features.

 

tag search, see ctags
fuzzy search, see fzf

multiple files, yeah it can do that with :buffer

vim's use of the unix philosophy to use other command line tools for extending features without bloat is another thing they got write.

 

I used all of those methods.

But modern editors such as Sublime and VS Code still provide a much better experience in those categories.

well one is more than welcome to use what they like. but please give examples of how x is better than y.

in this case, fzf and ctags also work with other tools out of the box so my email (mutt) client, file manager (mc), chat (bitlbee+irssi), and others has fuzzy search and tags. With that whole environment portable to thousands of machines online via git clone or docker image instead locked to one desktop.

 
  • opening multiple files: open in splits or tabs, search through open files with fzf
  • opening multiple projects: personally I use tmux for that
  • syntax highlighting: polyglot
  • file navigation: vinegar, nerdtree or just fzf
  • fuzzy file search: fzf or rg or ag etc.
  • tag search: gutentags with fzf backed by ctags

Far and away better than VSCode especially on code bases with a lot of files - the command t plugin for Vim (I personally use fzf on smaller code bases) happily works across millions of files.

 

I don't know about the editors themselves but I'm pretty sure that Vim key bindings (which is available for many popular editors via plugins) will make you (hopefully) more productive at editing text which increase the productivity of developing code since it requires typing a lot.

Even though I struggled quite a bit at the beginning of learning Vim and Vim key bindings, I highly recommend every developer to try to be comfortable with Vim key bindings and enjoy their faster code editing with less typing for the rest of their coding lives.

 

Things I like with Vim;

  1. Running commands on the shell then pasting the results into the buffer
  2. It blends very well in a multi-panel tmux session
  3. I can go to the top and bottom of the file with gg and G
  4. You don't need to the reach for the mouse

There are lots of other things, but these are probably the top 4 for me.

I generally don't want to recommend Vim, or any editor for that matter, to anybody. I think people, most specially coders, would like to try out lots of editors before they gravitate to their preferences. Then at at that point, they should just use whatever feels very natural for them. To each his own, I guess.

 

I prefer to recommend that developers try both vim and emacs at some point - that leaves the decision of whether to learn either (or both) entirely up to them. Personally, I know both, although I gravitate towards vim in the command-line. A lot of devs are scared off by the respective exit commands alone, so it takes some encouragement for them to try those editors in earnest, I believe.

That said, I do recommend that Linux ITs and sysadmins learn at least one power-user text editor. The time taken to learn vim or emacs quickly pays for itself when maintaining a server. (nano is a terrible option for that purpose.) Even if one has managed to set up their IDE or fancy window-system-based text editor to be able to edit remote server files, one should still know a good command-line editor; you can't always connect your favorite machine to the server when a fix is needed!

 

Actually, VIM is one of the most favorite thing i'v discovered. It's so cool, i don't have to use a mouse to navigate when i code anymore.

But...

It's painfully when come to config and install suitable plugins for vim. :(

I do know, it's worth. But it's too hard to make everything work perfectly as i want.

I'v pay weeks, even months to make my own vim config. (There are a lots of .vimrc sharing in the internet, but we can't just use other people configs..you know...Only we know what we need, what we do want to use...)

I'v tried so much to create mine configs. But it's never make me satisfy...

Maybe, i'll try it again in the future, but not now. Because currently, VSCode is the one that suitable for me. It have everything i need: Terminal, Split windows, Smart autocomplete...etc.

But how can i live without vim, i have to use VSCodeVim, which let you have almost all basic key mappings in vim. It's not the best, but it work for me :). Do you guys use it too ?

Again, i can't live without vim :)). I'm even install a plugin call Vimium on chrome, which let you use some basic navigation in chrome :))

 

Well rounded perspective IMHO.

I was an emacs person for 10 years before I embraced Vim. And, relative to job requirements, I used several other editors along the way (for years each) -including Eclipse, Visual Studio, and several others -all of which I used some form of 'vim mode'. Each of these editors requires a time investment. And with that said, I think your comment about Vim being "truly is a time-sink" is spot on.

Any time I've interviewed a developer or admin over the years one of the first questions I ask is: "What editor do you use?". By that question I'm not judging the answer but only that the person has an answer. Often the best candidates have been the ones who will say they have 'some' primary editor and adjust otherwise.

Nice article.

 

I truly and objectively believe vim does make me more productive. Some other stuff not necessarily related to text editing are way more important, but since I'm willing to pass a lot of time of my life coding, investing in optimizng the text editing process is really important.

While editing text, before vim I've noticed what takes the most time is figuring out how to do what you want to do in the minimum amount of time. Vim solves that problem beautifully, at the cost of being hard to learn. It comes to a point vim makes you spend less time thinking

I feel vim is like learning a new language, it's hard at first but once you master it you don't even think about it and do everything really naturally and fast, whereas previous text editors felt like using Google translate everytime I wanted to express myself.

It really comes to this: optimizing your process to the point you don't even need think about it, it all comes naturally to do boring stuff fast. If the tool you use is impairing you from getting to that point, maybe it's time to change tools. That's what happened to me.

But text editing is just a fraction of the big picture. Planning well your code - and your day! - beforehand, knowing how to better navigate through code to find fast the information you need, improving readability and designing an architecture that allows you to make changes easily are more important, specially because it might affect the overall productivity of your team.

 

Fiddling to make it work well for a new requirement isn't something that should take a significant amount of your time, so I don't worry about it. I've kept my vim config under version control for the last several years, and so I can tell you how often I've mucked about with it. Three times, in the last six years.

So I've spent less time mucking about with my editor config, which is at least a little bit productive, than I have on utterly unproductive stuff like configuring my machine to use the corporate-VPN-of-the-week (I'm up to three this year so far and that's without changing jobs) or on explaining our unchanged deployment process to product managers (about once a month).

But I would never try to push anyone to use vim. I don't care what editor anyone uses. If they want to use Sublime, or emacs, or Komodo, or ed (or even ED) that's fine by me, provided that their code works, meets our coding standards, and passes code review.

 

I think I'm echoing some of the other comments here, but I was intially attracted to vim because I wanted to be a power user. I have probably spent weeks worth of time customizing and tweaking it, even picking up a little vimscript along the way. My life got tremendously better when I stopped trying to make vim "perfect". I reduced the number of plugins I use (no completion needed with default control p and n, no syntax highlighting, etc). I wanted a universal tool to help me write code that didn't get in my way.
So while vim itself didn't make me a better programmer, it certainly made me appreciate the "right tool for the job" mindset. I think vim is one of the best text editors that you'll find, but if you want more, well, find what works best for you I guess

 

I both agree and disagree with this post. Vim doesn't compete with the capabilities and tighter integration other IDEs have but affords you the flexibility to customize the experience with the many off the shelf plugins and tweaks, etc to make it your own for your needs - that's harder to do with the all-in-one competitors and where it is possible, you are boxed in and limited. Have a new company DSL that has custom dev/test work flows and complex integrations with git? OK, write your own nominal syntax/plugin, hook in with vim autocommands that run custom tests in the background, have fugitive manage your git CI/CD,etc. Overheads? Sure. But manageable. Take vim away from me and I'm paraplegic. Give me something else in its stead and I'm dysfunctional.

 

I tend to agree, it's the navigation and some other best tricks that make vim so pleasant to work with. The package management is a bit of a pain though. A couple of months ago I decided to give emacs a go and soon afterwards I stumbled across evil mode and soon after that I discovered spacemacs. Spacemacs is fantastic all the joys of vim without the pain.

 

To be honest, mouse-less access to any file I need to edit locally or on a *nix server. Vim keyboard shortcuts have been embedded into my brain since Uni days. But when it comes to heavier languages like Java I'd use an IDE not something like vim.

 

surprising, I've found that vim can do java development. one also needs Gradle and to actually understand java but that's a good thing.

 

I never customize my vim. I have mostly pursued vim in VSCode and in the terminal. I enjoy not touch the mouse to move around and navigate. I've been using it for years and have not managed to use all the features of it.

 

the constant tweeking time sink to vim is a symptom not the norm. with releases like neovim and onivim one has those same tweeks baked in.

Honestly thought, if one is only using vim for home row navigation then they're missing the point. try to disable cusor movement by unbinding the keymaps and start to use vim mode as it's intended, a command prompt.

did anyone know that :r!foo.sh will actually read into the current buffer the strout of "foo.sh" or :split !fu.sh will bring a new horizontal rule window with the output of that shell command?

how about :set makeprg=... ? or the scripting language that's built-in?

I'm proud to say that vim has made me a better developer because it's been a tool which always is there, is built by programmers for programmers and just works for any use.

And that's the point of it.

 

I think the title is quite misleading and Vim the editor is not to be conflated with Vim the keybinding and editing philosophy. I also don't use Vim the editor now unless I'm performing quick edits on a file. I normally use Spacemacs and VS Code.

However, learning the Vim keybindings, even though it might be time-consuming, will give you far greater rewards for a lifetime to come. I think you're also not against learning the Vim navigation but you didn't express it well with the title.

I'd say learning the key bindings is already most of the battle and should be recommended to every dev. After that if one wants to learn Vim configurations they're free to do so. However that's not the key to productivity at all.

 

thank you. just, thank you!

You spoke my mind. To me, using vim is like joining the cool kids and dressing like them, there no reason to do that, but it's "cool".

I never actually found vim to be usable. It's cool, but there are so many other editors that are so much easier to use.

PS. if not implied, this is my personal opinion on vim :)

 

I'm a long time Vim user and I try to avoid doing tinkering with configuration at all. As long as I have syntax highlighting, which I find is almost always there out of the box in the latest versions, then I'm happy.

My config is in this article: dev.to/grahamlyons/why-my-developm...

 

The reason why I keep using and recommending vim to other developers is regarding the programming flow.

If I want to perform an action when refactoring, without vim I would have to use the arrows or worse, the mouse, to select and manipulate text.

With Vim, I can focus on the refactoring, without the manipulations breaking my mental workflow.

 

I only recommend Vim to people because I think it's critical for people to know how to use the basics eventually. At some point your going to have to ssh into a server and edit a file, and the best way to do that is to use Vim in my experience.

As far as pushing for them to move their whole environment to one centered around Vim.... idk. I think Vim is more enthusiast grade software. Yes you could move faster and do all the things, but some people don't NEED that and are perfectly happy moving at the speed they are now. To each their own.

I think Emacs is for a whole other level of insanity, but I love emacs, and have been using it as a daily driver for a long time. I only recommended it if I think the person is down for the roller coaster ride that can be emacs.

 

About productivity:

  1. Vim does not have to be a sink of time. Configuring plugin is easy most of the time. What take time is configuring it for your needs. Let think about it: if you configure it because you are annoyed to not be able to achieve some tasks, it means that you configure it to gain time.

  2. Every time I install vim on a new computer I just clone my dotfiles from Github and I have everything configured. I used PHPStorm before (good old bloated IDE) and it was a pain when I was reinstalling my system or even upgrade the damn thing.

  3. Nobody knows how to measure the productivity difference between somebody using Vim or an IDE. Going in one sens or another is useless to me without real data anyway.

At the end, Vim is fun. That's why I use it ; to me it gamifiy coding itself. This is the most important to me.

And you know what? I'm more productive if I have fun.

For those interested to know how and why used Vim instead of an IDE (in that case PHPStorm), I wrote a blog article about it: web-techno.net/phpstorm-vs-vim/

 

From a purely functional standpoint I compile primarily from command line with a watcher, and omnisharp is a trivial install. I run in a fairly basic setup and don't really feel compelled to configure a ton of plugins so my experience is probably more painless than those who do.

That said, I use any of 5 ides/editors daily depending on what I'm doing, vim is just one of them. I would agree in principle but still encourage people to learn to be comfortable in vim anyways. The more we get the industry at large using command line tools over gui tools, the better it will become.

 

I like vim because it's lightweight. I've used vscode and atom starts out great you're loving it. You pop in vim mode and it's an easy transition. But eventually because electron sucks. It slows down with more than 2 plugins. So I get very noticeable input lag, and sometimes freezes. I want to like vscode or atom but at their core they are just trash. So I stick with vim

 

I absolutely love vim, and I absolutely love Sublime. I also started using VS Code for my new job, and there are a few things about it that make me see why people use it. I think the moral of the story is that there is a place and time for every editor to shine, but I love vim since it works into my workflow well as a terminal junkie, but when I need all the bells and whistles that editors / IDE's provide, I use an editor / IDE. I think it's valuable to be at least familiar with a few editors depending on what you use them for.

 

VIM vs IDE is pointless, use the tool that makes you more comfortable.

A story for context. Once I met someone who uses Vim the team tried to convince him to at least use Sublime Text, then he shows us how quick he was and why he uses VIM. He likes to think everything, every line, so it suited it for him. We all think on what we code, but this guy really took her time.
On the opposite side, I use anything from Jetbrains, and I fly on it. I can create boilerplate with a shortcut or run custom cli commands.
I guess something that is never discussed is, VIM favors cli type of devs and GUIs hide favors visual type of devs.

I think every dev should learn both. I love my term I have spent hours pimping it and have done the same with my IDE's, so eventually, every dev gets rewarded by pointless tasks, but those things add up.

 

Midnight ramble of positive things that spending a buttload of time in vim has given me is:

  1. Reduced time to get comfortable using a new required editor.
  2. Rewired my brain to understand that autocomplete/intellisense is a luxury not a necessity.

For the first one, I just install the highest rated vim binding plugin and it's off to the races.

In my last job it was randomly having to use eclipse on a project. Now it's moving over Visual Studio 2017, let alone the time I've spent in Unity's little mono develop thing, XCode, PHPStorm, etc.

I already have vim movement and editing commited to muscle memory, I just don't want to waste the brainspace on adding more hotkeys to temporary text editors.

The second one is important to me, probably shouldn't be, all things considered.

 

I was using Atom for a while, but running a react app per text file didn't leave me with much memory for the development VMs I had to run. Since switching to Vim, my laptop no longer grinds to a halt.

And I can edit with higher-level tasks, like replacing a word, or deleting the contents of a pair of brackets, or moving between functions -- rather than having to translate every desire into a series of cursor moves.

Think of it this way: if you're using the alt key to move along word boundaries, imagine what it'd be like to have to code without the alt key. Vim gives you a great deal more of these things (what it calls "text objects") and once you get used to having them, you don't want to go without them, and IMO they more than make up for having to know which mode you're in.

Beware the blub paradox:

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

 

Vim is the friend you meet whenever you go and you always stop by to have a chat. No matter how cool you current editor is, at a certain point you will need to login into a server and you will have to choose between nano and vim. You make your choice.
Also, I code mainly using intelliJ with the standard editor, but with a shortcut I can enable ideaVim to do some nasty columnar ninja stuff and then I go back to the normal editor.
I wouldn't suggest to use only Vim for developing, but knowing it will help you in several situations.

 

I often use VIM because I can access anything anywhere anytime.

I do not use it in a productivity environment when I code on a single project for a while.

I use it to manage my servers without any interface, with minimal requirements and a lot of productivity when you can access all your computers around the world with simple commands, download files, read logs, manage configurations, etc.

Vim is productive when used for those reasons.

 

It is all about vim's navigation for me. I use VS with a vim emulated plug in. I loved vim editing in my browsers toxt boxes (plug in was unstable so I removed it). Sometimes wish bash had vim instead of emacs shortcuts.

 

I started using vi when it came out. I still use vim. For most things I prefer an IDE, however vim is still better for searching within a huge file, and for doing things that are highly repetitive. My third favorite editor is Excel. In Excel I build custom code generators for my ORMs.

 

I use Vim. I like Vim. I am more productive with Vim. But it's not twice as productive, it's more like 5% more productive.

If not Vim, I'd be using an IDE. Either Xcode or Visual Studio. As source code editors, they're okay. (For other capabilities, there are some things I really like about Xcode, some things I really like about Visual Studio. And then there are things that one does great, and the other does poorly. And yet other things where both IDEs are infuriating. Meh, go figure.)

My stance on the general push for Vim is "It's too late for me! Save yourself!"

My fingers know Vim, tacitly. When I use other editors or IDEs and I feel claustrophobic and hobbled.

PS: I used to be an emacs user. Started using vi on a bet / dare / challenge, and never went back to emacs. In hindsight, I think the one thing that emacs lacked was a good editor.

 

I agree that vim has a learning curve and to learn enough of vim to be productive takes a long time, but hear me out. First off, any IDE is bloated and there are a lot of things going on undercover that a developer may or may not be aware of. So if you develop in vim, all the time that takes to setup your project and environment may actually help you code better. Secondly, vim is ubiquitous and preinstalled in almost everything. So knowing how to use vim is a great asset and practicing vim with your day to day development with make you better at vim.
Last thought, I'm a passionate guy and I suggest vim over almost everything although I have been using vim for just over 3 months and I don't have as much knowledge about vim as I would wish to.

 

I think the biggest reason I tend to go to vim, or as I put it the modal editing aspect, is something that has stuck with me since reading 'The Pragmatic Programmer', pick a flexible text editor and stick with it. After seeing editors come and go, I find it difficult to commit time to something that I cannot be sure of 10 years from now. Vim style editing will be around for a long time, add in the fact that I can use vim-modes in whatever IDE /system/computer/terminal/... You get the idea. It's flexible, it's available, and I can expect it to be around for a long time.

 

IME, vi[m] has exactly one killer feature: ubiquity. You can rely on it being present on any *nix installation, and it's often in windows cygwin installations.

If you're pretty much always working on the same local machine, vim probably doesn't make a ton of sense for you. But if you find yourself not-infrequently using random machines, or if you're frequently working on machines over ssh, then vim gets you a lot of bang for your buck... up to a point.

IMO, there are probably only 2-3 dozen things in vim that are worth internalizing: basic movement between files/buffers, movement within a buffer (by char, by word, to beginning/end of a line, up/down by page or half page, to top/middle/bottom of screen, to beginning or end of buffer), region selection, cut/copy/paste, indent/outdent search/replace (including basic regex), and of course how to save & exit. Also, visual (rectangular) selection is incredibly handy every once in a while. That handful of things will comfortably cover 99% of the cases where vim is best used: small files, remote machines, and fresh installations.

In terms of ubiquity, plugins can easily become a trap. Relatively superficial things like syntax highlighting are probably fine, but anything beyond that is going to trip you up when you've remoted into a fresh install and suddenly discover that, e.g., there's no autocompletion. Things like that can totally mess with your muscle memory and your workflow.

If you want to take things a step further, remember that *nix itself is a reasonably complete toolchain/dev environment. Get comfortable with other command-line utilities (grep, find, etc.) and GNU screen (this is better than other multiplexers like tmux, IME, only because of its relative ubiquity) -- this will allow you to create a virtual workspace with multiple shells, all of which will survive connection outages and which can be accessed by multiple client machines. It also makes it easy to switch between shell(s) running vim and others in which you're running linters, compilers, etc. -- again, there are probably only 2-3 dozen things worth internalizing about screen; after that you're into diminishing returns. Trying to force vim to be everything goes against the basic Unix philosophy of having a bunch of relatively small, focused tools that are used in concert with each other -- it can be done, but it's inefficient.

In my mind, vim is like a good Swiss army knife, while IDEs are like a well-equipped work bench. A little knowledge of how to use a pocketknife can take you pretty far, if you're realistic about its limits.

 
 
 

I have to agree. I even use vim mode inside SublimeText. I also have that enabled inside Microsoft VS Code. I can't live without the vim navigation!

 

Vim is like a lightsaber. It can only do wonder in the hand of a Jedi. In the hand of a novice, it's existence is pointless. Not many can afford to train themselves as Jedi. What a pity!

 

I'll point you to the last discussion I replied about VIM. In which I say that Vim was made by the first guys to solve a rubiks cube after people stopped caring.

 

That said, Vim is a cool tool. I just don't the patience or time to invest in learning it. Especially when any dev environment I'm in has an equally as useful IDE or plain editor.

 

One should learn enough of ViM , so that, given a server environment one should have the same amount of productivity that one has while working on VS Code on desktop

 

If it is "more about Vim-navigation" to you then yes.
But to me, there are ton more than that.

 

I often work on linux distros with a ssh session. On servers you haven't an UI and a lot of editors, but vi is always available. I also like to use vim on my client.

 

Besides all things here said, coding mouse-less saves you a lot a lot of time.

Also, If you need to edit a file over ssh, you can't install fancy editors. vi comes to the rescue.

 

Personally, This video said it all...
(Thanks past me picking vim a try out of curiosity)
youtube.com/watch?v=wlR5gYd6um0

code of conduct - report abuse