Computer Puns Considered Harmful: Presented here are two old examples of harmful input sequences that might be called computer puns. Each has a double meaning, depending upon context.Xerox PARC's pioneering WYSI-WYG editor BRAVO [1] had a lurking danger. In edit mode, BRAVO interpreted the sequence edit as “Everything Deleted Insert t,” which did exactly that—transformed a large file into the letter ‘t’ without blinking. After the first two characters, it was still possible to undo the ‘ed,’ but once the ‘i’ was typed the only remaining fallback was to replay the recorded keystroke log from the beginning of the editing session (except for ‘edit’) against the still-unaltered original file.A similar example was reported by Norman Cohen of SofTech: he had been entering text using the University of Maryland line editor on the Univac 1100 for an hour or two, when he entered two lines that resulted in the entire file being wiped out. The first line contained exactly 80 characters (demarcated by a final carriage return); the second line began with the word “about.” Cohen said: “Because the first line was exactly 80 characters long, the terminal handler inserted its own CR just before mine, but I started typing the second line before the generated CR reached the terminal. When I finished entering the second line, a series of queued output lines poured out of the terminal. It seems that, having received the CR generated by the terminal handler, the editor interpreted my CR as a request to return from input mode to edit mode. In edit mode, the editor processed the second line by interpreting the first three letters as an abbreviation for abort and refused to be bothered by the rest of the line. Had the editing session been interrupted by a system crash, an autosave feature would have saved all but the last 0-20 lines I had entered. However, the editor treated the abort request as a deliberate action on my part, and nothing was saved.Two Wrongs Make a Right (Sometimes):A somewhat obscure wiring fault remained undetected for many years in the Harvard Mark I. Each decimal memory register consisted of 23 ten-position stepping switches (plus a sign switch). Registers were used dually as memory locations and as adders. The wires into (and out of) the least significant two digits of the last register were crossed, so that the least significant position was actually the second-to-least position and vice versa with respect to memory. No problems arose for many years during which that register was used fortuitously only for memory in the computation of tables of Bessel functions of the nth kind; the read-in error corrected itself on read-out. The problem finally manifested itself on the n + 1st tables when that register was used as an adder and a carry went in the wrong direction. This was detected only because it was standard practice in those days to difference the resulting tables by hand (using very old adding machines). Things have changed and we have learned a lot; however, similar problems continue to arise, often in new guises. Discussion:Today's systems have comparable dangers lurking, with even more global effects. In user interfaces, we have all experienced a slight error in a command having devastating consequences. In software, commands typed in one window or in one directory may have radically different effects in other contexts. Programs are often not written carefully enough to be independent of environmental irregularities and less-than-perfect users. Search paths provide all sorts of opportunities for similar computer puns (including triggering of Trojan horses). Accidental deletion is still quite common, although we now have undelete operations. In hardware, various flaws in chip designs have persisted into delivery.Many of you will have similar tales to tell. Please contribute them.Conclusions: Designers of human interfaces should spend much more time anticipating human foibles. Crosschecking and backups are ancient techniques, but still essential. Computers do not generally appreciate puns.