Re: Abort, Retry, Fail

Subject: Re: Abort, Retry, Fail
From: "Nancy S. Burns" <nburns -at- NOAO -dot- EDU>
Date: Tue, 19 Apr 1994 10:42:39 -0825

>Fred expands the discussion beyond the question of politeness, bringing up
>the tendency of many engineers to use violent terms when describing computer
>events. Examples: hit the key, kill the program, fatal error, bomb out,
>crash, blow up. Do you see these terms disappearing, as engineers grow up?
>Or are there more of them, emerging? I'd like to hear of other terms that
>equate computer use with warfare, or at least the kind of violence we see on
>TV.
>--Jonathan Price
>Communication Circle
>918 La Senda, NW
>Albuquerque, NM 87107

In John Shores's book, "The Sachertorte Algorithm and Other Antitdotes to
Computer Anxiety" (Viking Penguin 1985), he includes a section, "The
Language of Death and War". Here is an excerpt from this section which is
relevant to this list's discussion on violent computer terminology:

"...we say "execute" in the sense of carrying out, or putting into effect,
but that's not always obvious to the uninitiated. I'm not sure why we
"execute programs"rather than "process" or "operate" them (sometimes we
"run" them). It appears that the terms arose in the early days of
electronic computing, when computer programs were called "order codes", and
it was, in a sense, consistent to say the computer executed orders. But
even though we say "execute" in the non-violent sense, violent language
crops up a lot in computer jargon."

Shore goes on to say that although the jargon is violent, it does not
reflect actual violence. He suspects that it is "just human nature to act
out violent impulses in a perfectly safe environment."

Like most tech writers, I concur with Shore's statement that computer
jargon is not obvious to the uninitiated. I do not suspect that human
nature needs a safe environment to act out violent impulses, nor do I
condone using violent language as a way of acting out those impulses. As
technical writers, I encourage the use of constructive, empowering language
to convey to the reader what is happening or what she or he needs to do,
and challenge the use of destructive jargon that sends a message of fear
and doubt, paralzying the reader from action.

These are my personal views and do not reflect those of my employer.






Nancy S. Burns
National Solar Observatory
Tucson, Arizona
e-mail: nburns -at- noao -dot- edu

"Unlike most legal writing, and unlike specifications, the paramount goal
of user documentation is not to be unambiguous; it is to be helpful." from
"The Sachertorte Algorithm" by John Shore


Previous by Author: Re: Renaming help
Next by Author: Job hunting
Previous by Thread: Re: Abort, Retry, Fail
Next by Thread: women, computers, copyright, SGML etc.


What this post helpful? Share it with friends and colleagues:


Sponsored Ads