Twitter GitHub Facebook Instagram dirv.me

Daniel Irvine on building software

Beyond the IDE: Source code as text

23 September 2014

There’s a fascinating paper from Microsoft Research entitled Personal Distributed Computing: The Alto and Ethernet Software that details the rich featureset available on the Xerox Alto system. About half way down that page there’s a modestly-placed screenshot of the Smalltalk development environment. It’s most likely showing Smalltalk-80, circa 1983, but I gather that the features shown originated in Smalltalk-76.

Take a look at the window titled “System Browser”, the window hidden at the back of the Alto desktop. This window shows what is generally accepted to be the original class browser. The browser is used as follows: the user starts in the top-left list box, selecting first a class and then progressing to the next list box to the right, selecting an instance or a class method type, then proceeding in the same way across the screen until a specific method is selected. Then, in the bottom half of the screen, the definition of that message appears, along with a comment describing it.

Here’s the magical thing: this definition is editable. This is the default way of modifying a Smalltalk codebase. It’s not a text editor. There’s no file. The file system and a file structure doesn’t come into it. But you can edit your code by drilling down into an object graph and singling out a method.

It was this editing class browser that allows Smalltalk-76 to claim the title of world’s first IDE. It was a revolutionary idea.

So why then are we still using text editors to write source code?

One reason may be that object-oriented programming didn’t take the world by storm, and many people still-- to this day--write code files which run to hundreds if not thousands of lines in length. For all intents and purposes, these code files are text files. The need for commercial IDE vendors to provide a “one-size-fits-all” package meant that they could never, ever do away with the conventional text editor. Editing a badly-factored object-oriented system with a code browser would be painful. (Of course, one could argue that if you started your project from scratch with a code browser, the code base would be less likely to succumb to poor design.)

Speaking from personal experience, I believe there’s a second reason. Modifying a code base using a text editor is easier than using a code browser. For example, in a well-factored code base, if three code methods appear beside each other within the same text flow, chances are they are related, that they form some sort of cohesive clump. You want those methods to appear in a vertical flow--just like any text document--so that you can display them on screen at the same time. If you discuss these methods with a colleague, you can make use of the line number support within the text editor to help focus on different parts of different methods.

The text editor works just great for modifying source, and to that end what I really need is a great text editor like Vim, not a great IDE.

Now that’s not to say that a useful code browser could not exist: one can imagine a browser which displays a flow of methods that are related to each other, regardless of which class or file they belong to. Select a method and you see not just its definition but also the definition of all methods that it calls, and all methods that call it. But it still suffers from the same flaw, the falsism that all programs are composed of small, well-factored methods.

So I repeat--for now what I need is a great text editor, not a great IDE. And that’s likely to remain true for the foreseeable future.

About the author

Daniel Irvine is a software craftsman at 8th Light, based in London. These days he prefers to code in Clojure and Ruby, despite having been a C++ and C# developer for the majority of his career.

For a longer bio please see danielirvine.com. To contact Daniel, send a tweet to @d_ir or use the comments section below.

Twitter GitHub Facebook Instagram dirv.me