Tuesday, 09 May 2006

Writing for People and Devices

Even though it might be what Mr. Nelson intended, I don't really believe that Inform 7 is essentially about making programming easy for non-programmers. Or at least, it seems like a rather roundabout way to go about it. I also agree with those who say that, technically, Inform 7 isn't about natural language at all. Its real significance, at least to me, is that it is the latest experiment in writing for two audiences simultaneously: humans and computers.

It's a truism among computer programmers (the better ones, anyway) that the most important audience for a program is your fellow programmer, who may even be yourself at some later date. Many of the things we do to improve readabiity, such as comments and choice of program identifiers, have no effect on functionality, and yet can make an enormous difference when reading unfamiliar code.

However, sometimes readablity and functionality conflict. Making a program more readable can makes it slower, though it happens less often than some people think. (I've worked with people who objected to more readable code because it was more inefficient in some way, even if it's a way that might never become important.)

There's a trend in computer language design towards making these goals conflict less often. For example, compilers that do a good job of inlining functions allow us to create functions simply for readability, without concern for function-call overhead. There are also languages such as Python that aim to be "executable pseudocode," whose designers try very hard to make each construct be similar to what you would write when your audience is only other humans.

On the other side, some programmers try to avoid writing comments (which are unchecked by the compiler and therefore can go out of date) and instead embed design knowledge intended for human readers into the code, as program identifiers, by inventing suitable classes and methods, by writing clear tests, or even inventing new languages that allow end users to directly write examples of what a program should do.

The logical endpoint of this trend isn't that you can write whatever you like and leave it up to the computer to somehow extract whatever partial meaning it can (which is the point of real natural language projects) but rather that a good writer should be able to write something that is at once elegant English prose and precise instructions to be executed by a computer. This necessarily means understanding and following strict rules, but rules aren't necessarily just an obstacle. After all, many poets voluntarily limit themselves with rules without having it limit what they can say. Rules can even be used as a way to set up a challenge and then overcome it, as a way of showing off, for example when a limeric writer deliberately uses a word that's hard to rhyme.

So I don't think it's necessary for this kind of code to be easy to write. It might start out easy at the simple "the cat is on the mat" level, but I expect that learning to write code that is both excellent writing and defines excellent software is going to take practice. My hope is that those of us who enjoy this sort of thing will sometimes be able to write code that's downright fun to read, and that it reaches a wider audience than is typical for source code.

respond | link | /code