Visual Editors

While I sit here typing away at an especially depressing bit of code there's about 85 lines of Vim script trying to make the indentation look pretty by searching the nearby text for symbols it likes and trying to shift things around appropriately, using lots of regexes. At first this seems like a terribly inefficient combination -- the compiler already has a parser that knows where the structural elements in the source code start and stop -- why does Vim have to duplicate (poorly) this logic using regexes?

Of course it doesn't work like that: the compiler is designed to accept a complete, fully written program, and as a service to you doesn't tolerate deviations from the syntax, but the editor has to accept gross syntactic problems because you're just about to change it.

Which is one reason why linear flowing text is such a great way to represent what is really a hierarchical and rigidly structured document -- it's more flexible than the document it's ultimately going to be, so it can represent incomplete syntax. I can write this:

if ( ) {
}

And fill in the details later.

I was thinking about this because I was wondering why visual editors -- like LabView's flow thingy or EasyC or Scratch aren't more commonly used. I don't use them and all the ones I've tried annoy the hell out of me but in theory they seem like a better idea than pure text editors because they could do so much more. (Even super fancy IDEs that do a ton ultimately start from just text, which is why they will always screw stuf up (and get confused by incompletely written code)).

So what's missing? There are a few things I can see rigt away. In my opinion, to be useful visual editors must:

1. Avoid visual distractions

This is where EasyC is very good and Scratch could be better. Think about what a text editor gives you: small characters freely placed on a large, blank canvass. Blocks that fill the screen, excessive background colors (notice most editors let you use background colors in syntax highlighting and no one uses them) or lines and arrows cluttering up the space will just make you sad when looking at your code.

2. Represent incomplete syntax flexibly.

This includes incomplete syntax in all directions -- maybe you write a loop and omit the body, or maybe you write the body but omit the loop -- any conceivable way to omit parts of a program must be possible.

3. Give the programmer flexibility in laying out the code.

This might not be so much of an issue for structured imperative languages like C (though I think it's still necessary), but it would be absolutely inconceivable to write Haskell (or Lisp dear god) in a language that did the layout for you -- functions can be combined in too many different ways to derive the feel of a piece of code from the syntax.

This gets at a deeper point which is that editors must be able to communicate more than the code; they also must communicate what the code means in your head, by more than just identifier names and comments. Python tries to wrest this ability from you by using indentation to indicate blocks, and to some extent does succeed in frustrating me like that but they left enough flexibility in the language to make the code expressive.

4. Not be marketed as a kids' toy.

Because while many adults might be ok spending their days playing with a kids' toy, there is a certain age at which this is very unfashionable, and it's an age where a lot of programming gets learned. And a lot of habits are frozen.

5. Be as polished as a typical text editor.

I would never use EasyC for serious programming because it jus takes too much pointing and clicking, and it's slow. The thing is, even if text editors are starting out from a disadvantage, they've just been around so much longer, so many more people use them, and have acquired so many more hours of development and testing that most of the sharp edges have been worn off. And with a tool that you interface with constantly it matters less that it have a clean design than that the sharp edges be removed.

This last point is also why I keep using Vim, despite the many horrific stories I have accumulated while using it. Like how I was wondering why paragraph formatting in comments works strangely -- it formats them OK and keeps the leading '#' but it seems to hit everything in the comment even when I use 'gqip' to get just one paragraph. The reason (of course) was that Vim over the years has acquired two entirely different ways of delimiting paragraphs: the one used to format paragraphs by gq, and an entirely different one used to capture a paragraph with ip -- the former being a series of hacks for getting around things like comments and lists and the latter being a huge list of NROFF macros describing spaces and such. But I keep using Vim because most of the sharp edges have been hacked away and it's scriptable so I can get rid of most of the ones that still bug me (except paragraph formatting which I don't have the energy to tackle).

This last point is also the reason I think it's unlikely we'll get away from programming in text any time soon -- there's just too much effort put into text editing to make it worth starting from scratch. NI is trying with LabView, and a number of researchers are trying with tools for kids to program. (Notice both of these are about getting people who otherwise wouldn't be programming (scientists who have other stuff to do, or kids who have other stuff to do) to do so in a very limited boxed-in way -- but importantly the target is people who don't have preconceived notions about what programming is. The scientists aren't going to turn into the next generation of software developers but the kids might -- maybe they'll change stuff. And maybe I'll hate it and end up complaining about how kids these days do it all wrong. But oh well.)