You will pry vim from my cold, dead hands

I get funny looks from people quite often.

Random person: "What IDE do you use?"
Me: "I don't use an IDE unless I absolutely have to. I use vim."

There's that funny look again.

"Why on Earth would you use something so archaic?!"
"How can you live without a GUI-driven debugger?!"
"Why would you want to spend half your life configuring your editor?!"

Those are just a few of the typical questions that accompany those funny looks. Here are my typical answers for posterity's sake:

On using an archaic editor

Yes, it's archaic. But hey, there are advantages to being archaic other than being able to pull the old "I've been doing this longer than you've been alive" line. Because it's archaic, it's literally the single most commonly available editor on *nix-based systems. If vim isn't available, you can usually rest assured that vi is. If you're accustomed to most of vim's basic features, you won't feel entirely out of place in vi. In today's world of distributed systems, having the ability to speak nearly each and every distro's editor language is an incredible useful skill. I feel as much at home editing on a RHEL system as I do on Debian as I do on OSX.

On living life without a GUI-driven debugger

I've actually found that there's elegance and freedom in using command-line debuggers directly. Yes, there is a relatively steep learning curve (I'm looking squarely at you, gdb). Yes, setting a breakpoint will likely take longer when on the command line or may be a little unintuitive (I'm looking squarely at you import pdb; pdb.set_trace()). And yes, once you get into bed and begin to love using command line debuggers, you may catch yourself spending hours trying to continue living in your beautiful, magical world with languages that don't support it or support it very well (I'm looking squarely at you Java).

But, once you get past those hurdles, the flexibility and power that you have at your fingertips is really unparalleled by anything else. Oh, and did I mention that debugging on a remote machine is as easy as SSH'ing into it and running the debugger in the shell¹? Good luck getting your <insert favorite IDE here> to do that across bastions or docker containers².

On spending half your life in config

Well, here's the beautiful thing: I don't. To be fair, there was a day that I spent a ridiculous amount of time configuring a zsh shell and ran all ridiculous number of vim plugins to be all 1337. Problem is, they're not easily portable, especially when you start throwing ephemeral containers and VMs into the mix. I learn to rely on the near bare bones offerings that vim has. Here's my current .vimrc³ (pathogen is only used for solarized):

execute pathogen#infect() "-------------------------------------------------------- " general "-------------------------------------------------------- set nocompatible filetype on filetype plugin on filetype indent on set nobackup set noswapfile let mapleader = ',' set noerrorbells autocmd! GUIEnter * set vb t_vb= " status set ls=2 set statusline=%t[%{strlen(&fenc)?&fenc:'none'},%{&ff}]%h%m%r%y%=%c,%l/%L\ %P " general set background=dark colorscheme solarized set tabstop=4 set shiftwidth=4 set showmatch set number set smarttab set linebreak set nowrap set autoindent syntax enable " rfc au BufRead,BufNewFile *.rfc set filetype=rfc autocmd Filetype rfc setlocal textwidth=72 softtabstop=3 tabstop=3 shiftwidth=3 " yaml autocmd Filetype yaml setlocal expandtab textwidth=79 softtabstop=2 tabstop=2 shiftwidth=2 " python set expandtab autocmd Filetype python,rst setlocal expandtab textwidth=79 softtabstop=4 "autocmd BufWritePost *.py call Flake8() " markdown au BufRead,BufNewFile *.md set filetype=markdown autocmd Filetype markdown setlocal textwidth=80 " rst au BufRead,BufNewFile *.rst set filetype=rst autocmd Filetype rst setlocal softtabstop=3 tabstop=3 shiftwidth=3 

The above is simple enough that I can easily set the most important settings directly within an open editor without having to open a reference guide or weed through hundreds or thousands of lines of configuration. But there's also just enough to keep me happily editing files in my primary language (Python) and make adjustments should I start writing other languages again.

At the end of the day

In no way, shape or form am I saying that one shoe fits all. I don't believe that everyone should adopt my editor of choice. It's not the One True Editor (although I'll never admit that in person). Yes, there is some masochism involved. It's simply the editor that has worked best for me over the years and even though I try new IDEs (PyCharm, VS Code⁴, Visual Studio, Emacs, etc), I always find myself coming back to the warm, comforting security blanket that is vim.

So yes, you will have to pry vim from my cold, dead hands.

1. Of course, this assumes that the debugger is available on the target system ↩

2. Although support for this may be getting better ↩

3. Yes I know there are little niggly issues with it, so pedants please put your pitchforks away.  ↩

4. To be fair, VS Code was the one editor that held my attention for the longest time. It's pretty damn slick. ↩