loading...

Vim won't make you a more productive developer

maestromac profile image Mac Siri Updated on ・1 min read

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 our time on our text editor of choice. Choosing to use Vim, in my opinion, ultimately won't make a huge difference with any other editor. The majority of modern editors are more than capable to handle the task at hand and are much easier to get started with.

You want to use Vim? Sure. After you are vaguely familiar with it, you will dive deep into Vim's ecosystem and soon learn about the variety of flavors Vim comes in and the many ways to manage plugins and configuration. Suddenly need to code in Java? well darn, you'll need to expand your code completion, syntax highlighting, and add additional functions like compilation.

And after going through all of that, would you argue that you emerged out of it a stronger better developer? Or would you say it was all but a distraction and the time spent there could've been spent on coding and learning about other facets of programming?

I use Vim daily and I love it, but it's kind of difficult for me to recommend it because it truly is a time-sink. What the folks rave about is more about Vim-navigation and not Vim itself, and that is easily solved with Vim-mode, which is available in most editors.

whatever this is

So, what's your stance on the general push for vim?

Posted on by:

maestromac profile

Mac Siri

@maestromac

I'm a refactor-loving developer and I promise you I have nothing to do with Apple's Siri.

Discussion

pic
Editor 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 feel the exact same way. The guy nailed it.

 

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.

 

Emacs does also work well for this purpose.

 

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.)

 

I agree with you. How they work on a guest machine while connecting to them via ssh ? They're can touch their gui icons ? I don't know...

 

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.

 

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.

 
[deleted]

I think I forgot to escape <

 

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.

Have you tried vim -u NONE?

[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.

 

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.:-)

 

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 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.

 

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!

 

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.

 

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 :))

 

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.

 

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.

 

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.

 

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.

 

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/

 

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 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.

 

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.

 

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.

 

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.

 

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.

 

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