Friendly interface considered harmful

by Victor Wagner

I keep six honest serving-men
(They taught me all I knew)…
Rudyard Kipling

“Friendly interface” has become a term universally accepted. Nobody seems to ponder on the message of those words. But pondering over the phrase gives you the shivers: the programs though creatures of our mind seem close to conquering the world while definitely breaking loose of our control.

Friendship is a peer-to-peer relation, after all. It is Ok to speak of a human friend, a friendly country, but a “friendly hammer” or a “friendly fountain-pen” sound weird. Even among the entire animal kingdom only dog claims the title of a “man’s friend” (even if the best).

Programs indeed differ from other tools approaching the articulate speech of a kind. They are at least sometimes up to a coherent explanation of what goes wrong.

But programs still remain our own creatures. A creature forgetting itself and challenging its creator for equality was amply disambiguated in The Book of Genesis.

True, the English “friendly” may mean no more than “amicable” or “amiable”, not always referring to cordial friendship, unlike its equivalents in some other languages. But even the above epithets would sooner suit to describe a fellow road-wanderer or a marketing type hawking his goods around. That is, someone pursuing one’s own ends.

Why on Earth, dare I ask, a program that I have personally installed at my own hard disk and that I have fed with electric power bought with my hard-earned money should be privileged to pursue its own goals as distinct from mine?

Programs are no more than tools. Do we remember the ancient name for a speaking tool? Right, it was slave. And this is how a program should be positioned towards a man. A good interface should be slavish, not friendly. No hobnobbing, no backslapping. “How can I serve you, Master?”, “I gladly obey, Master”, and nothing above, unless something really claiming attention turns up.

What I like about Unix-like systems is their traditional utilities consistently implementing the concept of slavish interface. One of its manifestations is found in frequent absence of any output following successful execution of commands. The order fulfilled, there remains nothing to speak about. It is the case of failure that requires the reporting of reasons.

Note that “friendly” programs habitually “shriek” about their problem system-wide throwing up a modal window blocking all actions until you respond. Command-line utilities behave quite differently—if you work in a multi-window environment, the message stays in the window where the utility has been run until you, the master, choose to pay your attention to the faulty slave.

And even if you work with a teletype terminal lacking both windows and even virtual consoles, an error is usually treated by the program as a caution to suspend any activity, to clear the “battlefield”, and to offer its master a chance to investigate the issue.

Another drawback of a “friendly” interface is the utmost particularity in treatment of the user interface by its developers. Meanwhile, no longer than thirty years ago a principle was formed, reading that if one is too lazy to read the output of a program, one can always make another program do it. Live incarnations of the principle are “yes” and “grep” utilities that are part of any Unix-like system. All that “yes” does is generating infinite stream of yes’s to any questions asked by the program to which its output has been piped. Thus the user easily avoids the necessity of attending the screen and pressing Enter to popping up questions. Monotonous job is not for the free, it is the slaves’ lot.

“Grep” utility function is something of an opposite: it reads the output of some other program and chooses the lines of interest to its master. A kind of an executive assistant. And a well trained assistant at that: it can be assigned sufficiently flexible search patterns using the so called regular expressions and then it can be tasked to present the results in varied forms, restricted to the number of expressions matched, or to file names, or to all the lines containing matching patterns, or to the lines coupled with their neighbors above and below. Besides that, there exist still more sophisticated variations of “egrep” and “agrep”.

A generic Unix way of solving a problem is to decompose it into simplest possible subproblems each solvable with some of familiar utilities and then to combine them with a pipe—the “conveyor” dragging results in chain order.

This is much like verbal reformulation of the problem: “Read the mailbox, choose the lines starting with ‘Subject’, sort them alphabetically, and remove duplicates” turns into:

cat mbox | grep '^Subject:' | sort | uniq

In fact, this is it. The set of commands you operate is the language you use to issue orders to the machine. Kipling, the writer, used to call ordinary English words his honest serving-men. For a computer user, commands of an operating system are honest serving-men.

Don’t let the thousands of system commands (my humble laptop has 1411 executable files in its PATH) put you off! The vocabulary of a literary language contains hundreds of thousands of words although proverbial Ellochka “The Cannibal” from Ilf’s and Petrov’s novel happily made do with no more than thirty in her day-to-day routine. OS command frequencies have a very similar pattern of distribution when used.

Note that in the “friendly interfaces” realm, treating a program as “thing” (that can be manufactured, sold, bought and used), and not as words in human—machine communication, prevails. Such interpretation is indeed advantageous for software producers. We are accustomed to paying some price for all things, however graceless. But we would only pay for words if they prove talented. On the other hand, few people choose to make a piece of furniture or radio receiver themselves. It is easier to buy one. But any literate human is able to verbalize a reasonably simple thought.

This is why the software industry would be happy to turn computer users into program consumers. But does it pay off for a user? Imagine a hawk trained for falconry and schooled to be hand-fed. It is still capable of catching and killing a hare but it does not know that the hare can be eaten on the spot. Ceding the prey to its master, it is happy to get a share of meat the man chooses to treat it with. It is roughly the position of most computer users who are able to formulate a problem (to catch a hare) and even know how to solve it (to kill a hare). But they are not trained to “skin and eat” the hare, that is to turn words of the solution into a sequence of orders for their machine. This means it is software producers who get the lion’s share of the hare.

What the user has been left with are “friendly-interfaced” programs with their incredible self-importance and heaps of dumb mechanical efforts required for formatting technical documentation with a common-purpose word processor or using a desktop calculator ignoring the powerful electronic spreadsheet at hand.

This happens because if you treat your programs as things, it first of all means you do not understand the importance of wielding them. Whenever a new challenge arises, a new tool is bought or downloaded. Programs understood as words facilitate a different approach: they encourage couching the task in “words” already known to the machine. Moreover, the result of the phrasing can be anytime aliased with a single word.

Free Software movement as such emerged to counterbalance the programs-as-things trend. When the software industry first came out, many observed that it contrives to deprive users of control over their machines. While Richard Stallman went further stating a strategy for resistance—The GNU Manifesto.

The strategy is essentially simple: if you write a program useful for yourself, you are willing to share it with your fellow programmers. A copy of the program you retain will indeed serve any further needs.

Obviously, the active participation in the movement is open only for those who can solve their problems off their bats by creating new programs. That is why the programs useful to programmers surface as a rule sooner than those solving end users problems. The GNU C compiler, for instance, was created almost a decade before the GNU Image Manipulation Program (GIMP) appeared.

So what can the end users, not being programmers, do to make their computers obey them? Just a couple of things: to understand its workings and to master the ability to convert their thoughts into available “words”. The boundaries between solving end-users tasks and programming are ephemeral. Using shell aliases, word processor macros, one-liners in shell would already mean engaging in full-fledged programming. When dealing with computers, programming is as natural as speaking in prose was for Monsieur Jourdain from Molière’s play.

First published in «Домашний Компьютер» magazine, No. 12, 2002.
© 2002 by Victor Wagner. All rights reserved.
© 2014 by Victor Wagner, translation from Russian by Maksim Otstavnov. All rights reserved.

Victor Warner graduated in geography but has worked as a programmer since mid-1990s at Institute for Commercial Engineering, Communiware.Net, Cryptocom, and Parallels. Victor is probably best known for implementing Russian cryptographic standards for OpenSSL as well as for creating “catdoc” and “xls2csv” utilities, the latter being part of most OS distributions. He is also a sci-fi writer.