When I hear someone I respect rave about a software tool I’ll take a look at it. When I do, it often leaves me cold and I wonder how they could think it’s so great. Is this person just easily impressed? I think I understand now why this happens.
Tools are used in a context, and that context is often missing from a discussion. Software developers talk more about their tools than how they string their tools together. In hardware terms, they talk about components but not the backplane that holds the components together. To understand how someone works, you need to know his or her backplane and not just a list of tools.
Tom Ryder had an interesting series of blog posts entitled Unix as IDE. He brings up some ideas that I believe would be of interest to people who don’t care about Unix. He’s talking about backplanes.
When you use Visual Studio or Eclipse as an IDE, that software is your backplane. It integrates your software development tasks. Many developers see their IDE as a godsend and couldn’t imaging working without it. Others disagree. It’s not that some people like an integrated development environment (IDE) and others prefer a disintegrated development environment (DDE). Some developers, like Ryder, have a different way of integrating activities. He explains that he’s not trying to condemn IDEs:
I don’t think IDEs are bad; I think they’re brilliant … In particular, I’m not going to try to convince you to scrap your hard-won Eclipse or Microsoft Visual Studio knowledge for the sometimes esoteric world of the command line. All I want to do is show you what we’re doing on the other side of the fence.
I found it interesting that although Ryder is fond of Vim, he’s not advocating Vim per se as an IDE. He sees Unix itself as his backplane and Vim as a component.
… the two grand old text editors Emacs and Vi (GNU Emacs and Vim) have such active communities developing plugins to make them support pretty much any kind of editing task. There are plugins to do pretty much anything you could really want to do in programming in both editors … the developers concerned are trying to make these text editors into IDEs in their own right. There are posts about never needing to leave Vim, or never needing to leave Emacs. But I think that trying to shoehorn Vim or Emacs into becoming something that it’s not isn’t quite thinking about the problem in the right way. [emphasis added]
I agree. I like Emacs, and I appreciate using one program where I used to use several. However, you quickly reach diminishing return when you try to do everything in Emacs. Ryder goes on later to discuss Vim and how it fits into his ecosystem.
Part of the reason Vim is thought of as a toy or relic by a lot of programmers used to GUI-based IDEs is its being seen as just a tool for editing files on servers, rather than a very capable editing component for the shell in its own right. Its own built-in features being so composable with external tools on Unix-friendly systems makes it into a text editing powerhouse that sometimes surprises even experienced users. [emphasis added]
Composability is the key idea of backplanes. See this post on usability versus composability.
Many developers live in Visual Studio, but what happens when Visual Studio doesn’t integrate everything you need to do? Some would say that Windows is their backplane just as Unix is Ryder’s backplane. They use the file system, the clipboard, etc. But if you want to be more automated, you have the option of writing Visual Studio plugins or writing scripts to glue things together using COM or PowerShell. The transition between doing something manually and automatically is steeper on Windows.