Text-editing for programming is pathetic

June 13, 2009

You give someone a configuration file and you tell them that mistakes in it are expensive.

They make mistakes all the time. They eventually get fed up and say to you: “Make me a graphical interface to these configuration options. Make it impossible to make mistakes.”

We’re moving to doing the same thing for programmers.

Let’s say I want to declare a new variable in my program.

Here’s what that line of code looks like, changing over time:





var r

var ra

var rad

var radi

var radiu

var radius

var radius;

You get the idea. In ten of the eleven states, the program is incorrect. Multiply this effect by thousands of programmer actions and you get errors. Errors waste time.

Instead, your environment should provide an “Introduce Variable” command.

Personality quiz: Did you just think, “What a terrible idea, that would be horribly kludgy and slow!” Or did you think, “Good thought, how can we make that work?”

Here is how I would design this feature. Let’s say variables v and r are already declared in the scope where you want to introduce a new variable called radius.

You click where you want to introduce the variable, and then type v. This is what shows up:

var new-variable;

If you hit the down-arrow, you would get

v = v + 1;

Let’s say in this language, in this scope, these are the only two possible expressions that start with v.

Anyhow, you have

var new-variable;

and you hit tab.

var new-variable;

Now you type r. r is already used as a variable name, so var r; is not a correct statement.

var r-new-variable;


var ra;


var radius;

You’re done! At every stage, you had a syntactically correct program, the interface provided support for recognition instead of recall, and your mind stayed focused on your program semantics instead of barely-relevant syntactic details!


9 Responses to “Text-editing for programming is pathetic”

  1. Dustin Says:


  2. neilconway Says:

    Personally, I don’t think this approach would lead to much improvement in productivity. Errors due to typing mistakes are typically superficial problems that are quickly caught by the compiler, and are relatively cheap to correct. The hard, expensive errors in most programs arise because the programmer’s typing was correct, but their intent was subtly mistaken. Given automatic completion in a typical IDE, most typing errors can be avoided, anyway.

    As it stands, an efficient programmer is likely to be an efficient typist; as long as your hands don’t need to leave the keyboard, typing is quite efficient and I’d expect would have a pretty low error rate.

  3. aran Says:

    @neilconway: I think it would be a big help for novices. There’s a whole class of painful beginner frustrations that could be avoided. For experts I think it would be a nice-to-have that might speed things up a little bit.

  4. Reynold Xin Says:

    What if I really want a tab character after v?

  5. aran Says:

    @reynold: That would only be possible if there’s some semantic place in the AST for a tab character after V. In that case it would be another option in the down-arrow menu. And if there’s no semantic meaning for the tab character, no tab for you!

  6. Reynold Xin Says:

    In most of the common languages, tab has no semantic meaning and is not captured in the AST. Most programmers, however, do use it to indent and beautify code. (I am not trying to argue whether we should use spaces or tabs here.) That said, I believe your proposal is a good approach, but for seasoned programmers, the “barely-relevant syntactic details” are their natural instincts…

  7. aran Says:

    @reynold: Yes, this is a good consideration. The proper engineering of the system will need to make allowances for programmers who wish to format their code differently from the code pretty-printer.

  8. Greg Wilson Says:

    Why are you representing the program as ASCII anyway? A CAD system doesn’t represent a blueprint as ASCII art. http://www.intentsoft.com/ (seem to) store (something like) the AST, then render in human-friendly form(s) based on context (MVC-style). Makes many of these issues go away…

  9. aran Says:

    @Greg: I think the text representation has numerous incumbent advantages. Installed base, training, familiarity, flexibility, etc. I would advocate the Intentional approach, but I think a text-editor-like interface is the way to do it.

Comments are closed.

%d bloggers like this: