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
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 |