What’s your backplane?

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.

Related post: Career advice regarding tools

7 thoughts on “What’s your backplane?

  1. This video also nicely demonstrates the value of easily composable tools. It’s done by examining a concrete example (ido.el in Emacs) which in my eyes gets the point across, nicely.

  2. >>The transition between doing something manually and automatically is steeper on Windows.
    Not sure I agree with this statement.

    I don’t find writing a VBA script or a powershell script any more daunting that writing a c-shell script on FreeBSD to automate a task. But then again, I don’t do much in the way of text processing either. :-)

  3. What I find daunting is not writing the script but searching the documentation of the object model. I thought that MS Office automation sounded awesome when I first heard of it. Very high level programming! But my enthusiasm quickly waned when I got lost in the API documentation (or lack thereof).

    There’s not a big difference between using a shell interactively and writing a shell script. But there is a big difference between using Visual Studio and writing a Visual Studio plugin.

    That’s really a difference between command line and GUI, not between Unix and Windows. The “Unix as IDE” article equates Unix with the command line and Windows with a GUI. Of course one can run GUIs on Unix and command line apps on Windows, though the other way around is more common.

  4. Chris: There are a couple directions you could take the backplane metaphor with Emacs. You could say that text is the real connector, that everything flows as text and Emacs is a tool for interactive text editing. That would be similar to how Tom Ryder views Vim.

    Another possibility is to say the Emacs Lisp interpreter is the real backplane and that the Emacs text editor is just a GUI on a Lisp machine. This perspective is that it emphasizes that if you want to connect everything through Emacs, you have to write Emacs Lisp.

  5. >>I thought that MS Office automation sounded awesome when I first heard of it. Very high level programming! But my enthusiasm quickly waned when I got lost in the API documentation (or lack thereof).

    Odd, I felt the same way when I had to dig through Lex and Yacc documentation. *grin*

  6. John: It’s funny you would (seem to) backpedal a bit from emacs “you quickly reach diminishing return when you try to do everything in Emacs” just when I started using orgmode and babel with R, sh, and awk “in anger” this week partly inspired by your posts.

    Once you have a “live notebook” of individual complex commands (mostly file-to-file filters) in org-babel blocks and can edit and bop around from code block to code block editing and re-executing, you get a level of reproducibility and traceability that the shell history can’t match.

Comments are closed.