Codecraft

software = science + art + people

Why you should use an IDE instead of vim or emacs

2014-05-13

With a title like the one above, you may be expecting a rant from an IDE bigot. I know there are plenty of flame wars on this topic, on both sides, and if I raised your hackles (or whet your appetite), I’m sorry.

This is not that kind of post. For one thing, I don’t take myself so seriously:

There's a keystroke for that! Image credit: xkcd.com

What I’m hoping to do here is point out some subtleties to this debate that don’t get a lot of airtime, and explain to my supercharged-text-editor friends why I work the way I do. However, I also plan to write a companion to this post, explaining why you need to learn a tool in the vim/emacs category, and I’ll have plenty to say on that topic as well. Hopefully that buys me a few minutes of an open mind. :-)

From a distance

If you step back from the debate over IDEs vs. supercharged text editors, and squint to suppress the details, you’ll see that most exchanges on this topic look like this:

Variant 1

IDE fan: "You should use an IDE because it has cool feature X. Text editors are weak sauce!"
VIM fan: "You don't know what you're talking about. If I install plugin Y and edit my cfg file, I can have all the goodness you're so fond of, and a whole lot more."

Variant 2

EMACS fan: "IDEs are so dumb. They take all this time to load, use ridiculous amounts of memory, and force you to use a mouse. They are slow. They just get in my way. Real programmers can extract a block of code into its own separate function, generate a unit test stub, and grep the entire codebase for similar refactor candidates with a single keystroke."
IDE fan: "That's the 'Extract' button on my toolbar."

I tend to roll my eyes at conversational threads like these, because:

Those who are really proficient in one of these environments, but not the other, usually overestimate the feature disparity.
This cuts both ways. All you vim experts, did you know that IDE black-belts slice and dice text as quickly as you, that they compile and debug with the keyboard, and that they have very powerful macro capabilities like the ones you love? All you IDE lovers, did you know vim and emacs can do tabs and outline collapsing and go-to-declaration and cross-project refactoring? If it's a question of power, and if we're talking about what's possible rather than what's standard, then I think it's six of one, half dozen of the other.
The shared assumption — that feature richness is the right yardstick for comparison — is wrong.
Theoretical power isn't very interesting. Most of us use only 10% of what either toolset offers.

But more importantly…

Observation 1: It's not about you.

As I plan to discuss at length in a different post, software engineering is a team sport. Yet if you look at the argument templates above, you won’t see much focus on teamwork.

We probably don’t notice this misalignment because we assume that what’s best for individual team members is best for the team as a whole. Often, this is true — but there are important counterexamples. John Stockton scored less points than he might have, because he was superb at dishing out assists to Karl Malone. Would a higher-scoring John Stockton have been better for the Utah Jazz? I think not. It was team points, not individual points, that Stockton optimized.

In programming, optimizing your own work while disregarding the habits, expectations, skills, and needs of others on your team might be a bad tradeoff. If you pick a coding standard that’s vim-friendly, but half the team is using an editor that can’t emulate it well, have you been smart? If your IntelliJ wizardry leaves your buddy in the dust during pair programming, have you transferred knowledge as effectively as you should? If you despise doc comments because you have no use for hover text in emacs, but half your team uses eclipse, are you playing nice? If you use a refactor wizard all the time, but it drastically bloats the diffs on a maintenance branch, are you really boosting team productivity as much as you think?

I think that this observation weakens arguments on both sides of the debate, but on balance, it undermines the supercharged text editor crowd more. No two emacs gurus configure their environment the same way, and souping up the out-of-the-box editor is usually a labor of love for the fan. Go read all the web pages that discuss how to customize vim or emacs, and then tell me I’m wrong. Unless your whole team is cut from identical cloth, you’re more likely to have more in common, and to have a higher level of out-of-the-box functionality, with an IDE.

Don’t forget the impact of the broader community in your calculations about team value. You can absoely write java code efficiently in emacs or vim — but the vast majority of java developers use Eclipse or NetBeans or IntelliJ. Why? What does this buy them? Well, their IDEs are constantly educating them about the latest and greatest thinking in the community. When Java 7 or 8 comes out, their IDE nags them to update. Help topics get refreshed. New samples, new project templates, new static code analysis features just show up. And the programmers learn, just by the nature of their toolset. Plus, their skillsets are more likely to transfer, to generate useful help for others on StackOverflow, and to be honed by others, if they’re in the mainstream.

A programmer who’s plugged in to community best practice, is likely to contribute more value to his or her team, over time, than one who’s learned an efficient way to work and isn’t interested in newfangled ideas. All other things being equal, of course.

A final thought about teamwork: consider the rising generation. In my experience, most young programmers leave school with more comfort in IDEs than in text editors. Since young programmers are continuously arriving, the value of working within their world view is worth pondering.

Observation 2: Software engineering ain't just coding

Besides reading, writing, and debugging code, what do you have to do to release software? If your world is like mine, you have to:

… and on and on.

You can certainly live and thrive in that complex world if you’re a fan of a powerful text editor. However, I’ve come to believe that a text-editor-centric worldview is a little too comfortable thinking of every problem as a mental models remain simplistic. After all, the tool you’re using bills itself as an editor, not an “integrated development environment.” Isn’t that suggestive?

The greatest advocates of unit testing, continuous integration, refactoring, and best practice that I have known in my career have all been IDE proponents. Most (but not all) of the best system thinkers I know are IDE-centric, as well.

I don’t think this is an accident.

IDEs show you a gestalt; they encourage you to think holistically about what you’re doing. If you write a method, and you don’t like the hover text that pops up to coach you when you call it later, then you are incented to change the doc comment for it, then and there — because the IDE integrates the whole experience. If you rename a method, and 7 red regions suddenly appear along the scrollbar for your file, you learn immediately how much you’ve broken. If you tweak the model in an MVC architecture, and the IDE is displaying the ER diagram and the table layout from the backing DB in a callout below your edit window, you are more likely to remember to make a complementary edit in that other layer at the same time. You are more likely to care about test coverage if your tool of choice tells you how you’re doing, constantly.

Where I'm at

If you peruse my archives, you’ll see that I’m a pragmatist. I use IDEs as often as I can, but I’m willing to drop into vim when it makes sense. I speak passable vim, but it’s not my first language.

I have no doubt that some of the folks who read this post will be awesome team players, great gestalters, and hard-core text editor gurus, all at the same time. That’s a cool combination of skill/personality, and I know it’s possible to achieve. And if you’re there, and you’re well into your career, maybe staying there makes sense.

However, what I’m suggesting is that on balance, for most engineers, the usual tool of choice ought to be an IDE instead — specifically, an IDE that other team members and the larger community use and like. This choice will pay off in enhanced teamwork benefits, and it will broad, integrated thinking that characterizes the best software efforts.

Right now, I actively participate in half a dozen codebases. Some consist of venerable, unix-style C; one is cutting-edge C++11; others are in java or python. The teams that maintain the older code cut their teeth on vim and gdb, and they still mostly live there. I wish I could convince them to try out IDE-land for a while; I think they’d find it easier to generate momentum on unit tests, to see their way past nagging tech debt. However, bigger concerns have kept me from pushing them hard in that direction.

Maybe this blog post will move the needle. :-)

As I’ve worked on developing my more likely to be realized in an IDE; where I’m headed, text editors won’t be enough.

My next blog post will be for the folks who live in the other codebases, and who may think that an IDE is all they’ll ever need. They have something to learn from the other worldview, as well…

Comments

  • kc5tja, 2014-05-13:

    It's not uncommon for me to have up to three different editors open at once on a single project (Vim, ACME, and Sublime Text 2). Sometimes, they'll even be editing the same file. Depending on the project, I might replace ST2 with NetBeans.

  • Daniel Hardman, 2014-05-13:

    I'm chuckling because that sounds so much like me. I often have vim running in 3 or 4 different windows, and half the time I open the same file more than once. I'll get in the middle of making mods with one tool, and then switch to another when I have some other change that's easier to do in the other window. Thank goodness all good tools warn you about changes to the file you're editing. :-)

  • Nitsan, 2014-05-14:

    Very nice read, thank you. But what can you do when most of your work deals with editing files on a production server, where Vim/nano are the only options you have, and you are forced to leave your beloved text-editor?

  • Daniel Hardman, 2014-05-14:

    That is an excellent question, Nitsan — and I have no doubt that you already know the correct answer. You use vim/nano. Usually, this is not the classic "software engineering" scenario where you have git, a ticketing system, scrum, and all sorts of process and complexity. But it *is* an important scenario to most of us, at one time or another. I have one other compelling reason why all of us should also learn a good text editor — not use it by preference for everything we do, but have it in our repertoire, as a useful skill. I'll discuss that in a follow-up post.

  • Nitsan, 2014-05-15:

    I believe a short video like this: https://www.youtube.com/watch?v=E2t2614cNAs can show the true power of sublime's workflow, which is easy to master, and vastly improve productivity. sublime is my tool of craft

  • lol internet, 2015-05-10:

    I use sshfs to mount remote filesystems in userspace.

  • Daniel Hardman, 2015-05-11:

    Yep, that also works, and I've done the same thing from time to time. Thanks for chiming in!