Why vim? Or: Why a text editor, not an IDE?

People (mostly at my school) have gawked at me when I say I don't use Visual Studio, or I don't use Eclipse, or I don't use Dreamweaver, or I don't use Word and use OpenOffice less and less. Instead I use vim. And the fact that I only have one substitute for all those giant programs speaks volumes about vim.

Of course, it's not just vim. I obviously use compilers and such. But whenever text is involved, it's almost always vim I end up using. I don't particularly like emacs, but they more-or-less have the same practices as vim users if a different philosophy. (Kind of how Christian Monk/Nun practices match up with Buddhist practices even if the philosophies are quite different.)

So I've grown into the habit of saying "Linux is my IDE." I use vim when I need to edit text, and use a host of Linux programs to manipulate that text. I use ant for my Java projects, Makefiles for C/C++ projects, gdb for debugging, $$\LaTeX$$ for documents and homework, and a browser to parse the templates I handwrite that compile down to HTML.

There are a few exceptions, of course, but they're in the work environment where stuff needs to get done sooner rather than later. One exception is Flex development: I use Adobe's Flash Builder for that, and it's really good. It's basically a fork of Eclipse as well so I've kind of learned some Eclipse methodologies along the way. A second exception is using Eclipse sometimes when I need to debug a complex Java program like LucidDB.

I didn't always use vim though. When I started programming, I used EditPad Lite pretty much exclusively. Of course I was exposed to other IDEs even then but I liked the lightness of EditPad. It didn't have syntax highlighting, it didn't have auto-indentation, it didn't have code-completion, it was just a really good, simple text editor that took 0 effort to learn.

I typed code by hand instead of copying and pasting. I also got lazy and didn't indent at all. So I had a great mess of grey, unindented PHP code, and it worked. I attribute this to my quick learning of standard PHP functions (along with PHP's great manual). EditPad didn't auto complete my code, I had to type everything.

So now when I do Flex development, I use the Flash Builder IDE. And I'm constantly doing ctrl+space which brings up a list of code suggestions and will auto-complete if there's only one. I've been doing Flex stuff for about a year now, and I still have trouble remembering actual names for things I want which made a recent vim project in Flex difficult. I've sacrificed getting stuff done quickly with learning something well enough to do it with any environment; Flash Builder has become a crutch.

I believe your ability as a programmer is strongly correlated with how much you can keep in your working memory at one time. This includes program structure, standard libraries for your language, language syntax, local variables, global variables, functions to call, external libraries, editor commands... The list goes on. With Flash Builder, I've taken away needing to remember a lot of ActionScript details, for the benefit of faster initial development, but at the cost of actually good code.

Recently I had to use the debugger in Eclipse for a Java project. Normally I don't use debuggers, even for C. (C++ on the other hand...) There are exceptions of course, especially in the C world when I'm not on a system with +debug for malloc() calls and I need to find a memory problem like a segfault. (My normal system tells me where it happened without needing to run gdb.) In Java though, needing a debugger is rare! But the LucidDB stack is over a million lines of code, and even after a year of working on it I still feel like I've only scratched a bit into the surface. This recent excursion was in the SQL Validator component. The code itself isn't that complicated once you understand what it's doing, but the call graphs and dependency graphs are insane, and I needed Eclipse to help me hold the relevant parts of it in my brain as well as help me figure out that "When it's in this function at *this* stage, it will do this, but when it's in this function at *that* stage, it will do that." Branching code is one of the tricky parts of programming.

Using a debugger is completely understandable and at times necessary to get your head wrapped around another person's (or people's) project. In my own projects, though, if I have to break out the debugger that sends up a big warning flag that I need to refactor and make the code simpler to follow. Debuggers point out your limitations as a programmer; those that are always in a debugger aren't improving, themselves or their code.

So I encourage people, especially beginner programmers, to just use a normal text editor. If you want to spend the effort to learn vim right away, that's fine too. Later on you might learn that vim has support for all the stuff the fancy IDEs do; I've started using code autocomplete for Python sometimes though I don't need to. But at the beginning it's important to think only about the code and to actually work with it rather than work with a copy-pasted form of it or an auto-generated form if it. Your finger memory as well as your regular memory needs to memorize at least a good chunk of the language and libraries you use so you can be a good programmer, and you're not going to get that with autocompletion. It's tempting as a beginner to take the easy way out and copy-paste someone's working code, but you don't learn anything that way. You might get the grade, you might make your boss happy, but those are not as important as actually learning.

---

Posted on 2011-07-17 by Jach

Tags: personal, philosophy, programming

Permalink: https://www.thejach.com/view/id/180

Trackback URL: https://www.thejach.com/view/2011/7/why_vim_or_why_a_text_editor_not_an_ide

Back to the top