My Name is Ishmael
Natural Language Interfaces, Part 11
Multiple Arguments
The Command Line has perhaps the longest legacy of of any software paradigm. It is beautiful in its efficiency and power. For many, learning the command line marks the first time where new hackers feel like they really get computers.
The structure is simple — first, you type the command, which is really just name of a program on the file system. Then, you type any number of arguments, to specify what you want it to do.
All of these arguments are ultimately just text, so to specify what each argument means, some of them are labeled (named arguments), and some rely upon being used in a specific order (positional arguments). I call these meaning markers.
This structure very expressive, as it means that commands can have dozens of optional arguments, each with their own meaning markers, each tweaking their behavior in small ways. However, it’s incredibly difficult to remember what each of these arguments does and how to specify them. For all but the most basic commands, most Command Line users find themselves looking at man pages (documentation) or simply Googling.
“Find someone on Stack Overflow who has done what you are trying to do” is generally not the best user interface, so higher-level Command Lines generally work differently.
Unfortunately, the solution that most of them land on is “only accept one or two arguments.” That way, it’s always clear and easy to remember, and you don’t need meaning markers at all. However, this severely limits the Command Line’s expressiveness.
Let’s look at the 11th rule of Natural Language Interface design:
The interface should accept commands with more than one argument
Imagine trying to have a conversation in which your sentences cannot have any adjectives or clarifying information.
My name is Ishmael. This happened in the past. I had no money. I was bored. I wanted to sail. I wanted to see the ocean.
Let’s take Alfred — the most popular high-level command line for Mac. Commands are limited to a single argument.
There are a few cases concerning files where you can use a complicated Object->Verb->Object structure, but this forces you to use a completely new and confusing interface.
How about Quicksilver, the granddaddy of Mac high-level command lines? Unfortunately, just like Alfred, most of the time you are limited to a single argument.
In the causes where you can specify multiple arguments, the same confusing Object->Verb->Object structure is used.
It seems there is just no way to have an interface that allows for many arguments in an easy-to-use way.
When thinking about these things, the most useful question to pose is this: How do humans do it? How can a secretary understand a sentence like
Call Mark and schedule an appointment with him for sometime next week.
That sentence has two verbs, two objects, two prepositional phrases, and a qualifier. And yet, any English speaker can understand that sentence effortlessly.
The reason is because language has meaning markers built in. That sentence has the equivalent of both positional arguments and named arguments, and you didn’t even realize it.
If you can teach a computer to understand those implicit markers, you can have a Command Line that accepts multiple arguments, but in a way that is effortless to use.
This means, of course, that your Language parser will need to be tailored to every different language, and it will need to accept some ambiguity. However, the extra power gained far outweighs the losses.
Lacona strives to extract the meaning markers from normal language, allowing for a much more powerful interface while still keeping the effortlessness of simpler approaches.
This is Part 11 of a 16 part series on the design of Natural Language Interfaces that is not being written in order. Read the introduction/table of contents here.
Full Disclosure: I am the author of Lacona, which is currently on Kickstarter. If you are intrigued, please back it. You’ll be glad you did.
