Why language isn't easy

(This article first appeared on IBM developerWorks.)

Peter Seebach ([mailto:crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net)

Freelance writer

September 2002

For many years, it was generally assumed that, any day now,

computers would be able to use natural language and then there would be no need for programmers. In this article, I explore a single facet of this argument and see why accepting natural language is so hard -- and, in practice, so frustrating -- for the user. I also look at a specific case where it works quite well.

Introduction

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop. -- Alan Perlis

One of the dreams to which people have long aspired is the ability to simply express thoughts in English (indeed, any natural language would probably serve) and have computers understand them. This problem has proven to be much harder to solve than once anticipated. It's easy to get a correct response from a computer some fraction of the time; even a large fraction can be managed, if one is diligent. However, in the end, the computer still guesses and people often find it incredibly frustrating.

The world is full of search engines and similar programs which proudly announce "Just type your question in English." Unfortunately, their results can be hilariously wrong. Users seem to be happier overall using a normal search engine, even one that requires "AND" and "OR" to be specified, rather than attempt to use natural language.

In fact, some of the best work in this field comes from the lowly text adventure. Much improved since Colossal Cave Adventure's parser (which understood words by their first four characters and recognized only verb/noun combinations), the text adventure is a good environment to study the issues that we encounter when trying to teach computers, not to speak, but to listen. Modern authors call them interactive fiction and the boundary between fiction and games is blurred.

Managing the language gap

Part of the problem, of course, is expectations; users are told to expect the full expressiveness they're used to when talking to other people, rather than told to expect that the system simply guesses at what they meant. Worse, because the rules are undocumented, the user can't choose to adapt himself to the needs of the program, except through exhaustive trial and error.

So, one way to improve the usability of natural language systems is to admit to their limitations and teach users how to most productively interact with such a system. Interactive fiction does this through tutorials, sample games and the like; users are gradually taught what styles of sentences the parser is most comfortable with.

Users have grown skeptical, and rightly so, of the ability of computers to understand natural language. This actually makes it easier to make products work, because users will habitually simplify their language use when dealing with computers. Nonetheless, it is difficult to dumb language down far enough for many of the email autoresponders out there.

Removing the guesswork

The worst part of the problem, however, is much harder to solve. Simply put, natural languages are incredibly flexible in the number of ways they can express even the simplest concepts. Imagine, if you will, the number of ways in which someone might express the concept of adjusting a wall calendar to see the next month's worth of dates: 1. Turn the calendar to September. 2. Turn to September. 3. Flip the page on the calendar. 4. Flip the calendar over. 5. Change the calendar to September. 6. Move the calendar ahead.

This gets worse when you have to consider multiple actions or contexts; words, which in one context are mostly synonymous, might change meaning entirely when taken in another context. This problem can be very hard to solve and, indeed, many games err on the side of allowing implausible actions, rather than trying to polish everything.

For an example of how not to solve this, consider the voice mail system I recently used which asked me to "describe what you want to do", giving no guidance at all as to what kind of description. It then repeated back the first two words it recognized out of everything I'd said and asserted that I would now be transferred. If my response were, "I don't want to change my service plan," do you think it would have understood? I don't.

While no short fix can solve this, a standardized format can help immensely. Interactive fiction systems generally resolve this by requiring everything to be a simple imperative, "Put the book on the shelf" rather than "I want the book to be on the shelf" or "I want the shelf to contain the book." Imperatives help focus language immensely.

Tailoring domain knowledge

One way in which interactive fiction systems are able to more easily model language is domain knowledge. The game's parser can make certain assumptions about the world; it knows every word it is expected to need and it knows the names and qualities of every object it must deal with. Expert systems are often able to use this. After all, for all the quirks of the voice mail system described above, it did start with the knowledge that any problem it was being called about probably involved cellular phones.

This is one of the reasons that general-purpose natural language parsing is very hard, while even children's games may be able to handle sufficiently simple subsets. In a small interactive fiction game, it's quite possible that a majority of the running code will not be the specific code written by the programmer for this game, but rather, the underlying world model implemented by the design system, which understands concepts like "containers" and "light sources."

Conclusion

Unfortunately, while it's possible to make a very playable game using a natural language parser, more complicated tasks -- not to mention more important ones -- may not be suitable. When playing a game, you can happily overlook the occasional misunderstood command. When programming heavy machinery, you can't. The strengths of natural language in human communication -- flexibility and nuances, for instance -- do not translate well to computing tasks. Meanwhile, the weaknesses of natural language, such as ambiguity, can be crippling for a computer.

It is not an accident that technical fields, from weaving through mathematics, have all evolved highly specialized jargon, nor is it an accident that many phrases and sentence structures become standardized. This adherence to rigid form allows more precise and reliable communication when it is necessary.

Attempts to combine these have simply produced ugly, clunky languages which are not measurably easier to use. Humans are more flexible than computers; it's easier for us to learn to use the computer's vocabulary, or a specific format in which to express our desires, than it is to try to get the computer to understand the fullness of natural language. Once we've decided to use a computer-specific language, much of natural language becomes irrelevant to the task; the use of articles on nouns becomes irrelevant and no longer adds information. Languages which insist on inserting the word "the" wherever a definite article would be used in English merely annoy the user rather than help him.

Nonetheless, you can have a lot of fun playing games which do give the illusion, however briefly, that the computer knows what you mean. Give it a try.

This week's action item: Download some interactive fiction and play it for a bit. Play around with the parser and see how well it does. Try things like "take everything but the torch."

Resources

About the author

Peter Seebach Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at [file://localhost/home/seebs/ic/crankynew/crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net.