Chapter 7

:bubble sort: /n./ Techspeak for a particular sorting technique in which pairs of adjacent values in the list to be sorted are compared and interchanged if they are out of order; thus, list entries `bubble upward' in the list until they bump into one with a lower sort value. Because it is not very good relative to other methods and is the one typically stumbled on by {naive} and untutored programmers, hackers consider it the {canonical} example of a naive algorithm. The canonical example of a really *bad* algorithm is {bogo-sort}. A bubble sort might be used out of ignorance, but any use of bogo-sort could issue only from brain damage or willful perversity.

:bucky bits: /buh'kee bits/ /n./ 1. obs. The bits produced by the CONTROL and META shift keys on a SAIL keyboard (octal 200 and 400 respectively), resulting in a 9-bit keyboard character set. The MIT AI TV (Knight) keyboards extended this with TOP and separate left and right CONTROL and META keys, resulting in a 12-bit character set; later, LISP Machines added such keys as SUPER, HYPER, and GREEK (see {space-cadet keyboard}). 2. By extension, bits associated with `extra' shift keys on any keyboard, e.g., the ALT on an IBM PC or command and option keys on a Macintosh.

It has long been rumored that `bucky bits' were named for Buckminster Fuller during a period when he was consulting at Stanford. Actually, bucky bits were invented by Niklaus Wirth when *he* was at Stanford in 1964--65; he first suggested the idea of an EDIT key to set the 8th bit of an otherwise 7-bit ASCII character). It seems that, unknown to Wirth, certain Stanford hackers had privately nicknamed him `Bucky' after a prominent portion of his dental anatomy, and this nickname transferred to the bit. Bucky-bit commands were used in a number of editors written at Stanford, including most notably TV-EDIT and NLS.

The term spread to MIT and CMU early and is now in general use. Ironically, Wirth himself remained unaware of its derivation for nearly 30 years, until GLS dug up this history in early 1993! See {double bucky}, {quadruple bucky}.

:buffer chuck: /n./ Shorter and ruder syn. for {buffer overflow}.

:buffer overflow: /n./ What happens when you try to stuff more data into a buffer (holding area) than it can handle. This may be due to a mismatch in the processing rates of the producing and consuming processes (see {overrun} and {firehose syndrome}), or because the buffer is simply too small to hold all the data that must accumulate before a piece of it can be processed. For example, in a text-processing tool that {crunch}es a line at a time, a short line buffer can result in {lossage} as input from a long line overflows the buffer and trashes data beyond it. Good defensive programming would check for overflow on each character and stop accepting data when the buffer is full up. The term is used of and by humans in a metaphorical sense. "What time did I agree to meet you? My buffer must have overflowed." Or "If I answer that phone my buffer is going to overflow." See also {spam}, {overrun screw}.

:bug: /n./ An unwanted and unintended property of a program or piece of hardware, esp. one that causes it to malfunction. Antonym of {feature}. Examples: "There's a bug in the editor: it writes things out backwards." "The system crashed because of a hardware bug." "Fred is a winner, but he has a few bugs" (i.e., Fred is a good guy, but he has a few personality problems).

Historical note: Admiral Grace Hopper (an early computing pioneer better known for inventing {COBOL}) liked to tell a story in which a technician solved a {glitch} in the Harvard Mark II machine by pulling an actual insect out from between the contacts of one of its relays, and she subsequently promulgated {bug} in its hackish sense as a joke about the incident (though, as she was careful to admit, she was not there when it happened). For many years the logbook associated with the incident and the actual bug in question (a moth) sat in a display case at the Naval Surface Warfare Center (NSWC). The entire story, with a picture of the logbook and the moth taped into it, is recorded in the "Annals of the History of Computing", Vol. 3, No. 3 (July 1981), pp. 285--286.

The text of the log entry (from September 9, 1947), reads "1545 Relay #70 Panel F (moth) in relay. First actual case of bug being found". This wording establishes that the term was already in use at the time in its current specific sense -- and Hopper herself reports that the term `bug' was regularly applied to problems in radar electronics during WWII.

Indeed, the use of `bug' to mean an industrial defect was already established in Thomas Edison's time, and a more specific and rather modern use can be found in an electrical handbook from 1896 ("Hawkin's New Catechism of Electricity", Theo. Audel & Co.) which says: "The term `bug' is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus." It further notes that the term is "said to have originated in quadruplex telegraphy and have been transferred to all electric apparatus."

The latter observation may explain a common folk etymology of the term; that it came from telephone company usage, in which "bugs in a telephone cable" were blamed for noisy lines. Though this derivation seems to be mistaken, it may well be a distorted memory of a joke first current among *telegraph* operators more than a century ago!

Or perhaps not a joke. Historians of the field inform us that the term "bug" was regularly used in the early days of telegraphy to refer to a variety of semi-automatic telegraphy keyers that would send a string of dots if you held them down. In fact, the Vibroplex keyers (which were among the most common of this type) even had a graphic of a beetle on them! While the ability to send repeated dots automatically was very useful for professional morse code operators, these were also significantly trickier to use than the older manual keyers, and it could take some practice to ensure one didn't introduce extraneous dots into the code by holding the key down a fraction too long. In the hands of an inexperienced operator, a Vibroplex "bug" on the line could mean that a lot of garbled Morse would soon be coming your way.

Actually, use of `bug' in the general sense of a disruptive event goes back to Shakespeare! In the first edition of Samuel Johnson's dictionary one meaning of `bug' is "A frightful object; a walking spectre"; this is traced to `bugbear', a Welsh term for a variety of mythological monster which (to complete the circle) has recently been reintroduced into the popular lexicon through fantasy role-playing games.

In any case, in jargon the word almost never refers to insects. Here is a plausible conversation that never actually happened:

"There is a bug in this ant farm!"

"What do you mean? I don't see any ants in it."

"That's the bug."

A careful discussion of the etymological issues can be found in a paper by Fred R. Shapiro, 1987, "Entomology of the Computer Bug: History and Folklore", American Speech 62(4):376-378.

[There has been a widespread myth that the original bug was moved to the Smithsonian, and an earlier version of this entry so asserted. A correspondent who thought to check discovered that the bug was not there. While investigating this in late 1990, your editor discovered that the NSWC still had the bug, but had unsuccessfully tried to get the Smithsonian to accept it -- and that the present curator of their History of American Technology Museum didn't know this and agreed that it would make a worthwhile exhibit. It was moved to the Smithsonian in mid-1991, but due to space and money constraints has not yet been exhibited. Thus, the process of investigating the original-computer-bug bug fixed it in an entirely unexpected way, by making the myth true! --ESR]

:bug-compatible: /adj./ Said of a design or revision that has been badly compromised by a requirement to be compatible with {fossil}s or {misfeature}s in other programs or (esp.) previous releases of itself. "MS-DOS 2.0 used \ as a path separator to be bug-compatible with some cretin's choice of / as an option character in 1.0."

:bug-for-bug compatible: /n./ Same as {bug-compatible}, with the additional implication that much tedious effort went into ensuring that each (known) bug was replicated.

:bug-of-the-month club: /n./ [from "book-of-the-month club", a time-honored mail-order-marketing technique in the U.S.] A mythical club which users of `sendmail(1)' (the UNIX mail daemon) belong to; this was coined on the Usenet newsgroup comp.security.unix at a time when sendmail security holes, which allowed outside {cracker}s access to the system, were being uncovered at an alarming rate, forcing sysadmins to update very often. Also, more completely, `fatal security bug-of-the-month club'.

:buglix: /buhg'liks/ /n./ Pejorative term referring to {DEC}'s ULTRIX operating system in its earlier *severely* buggy versions. Still used to describe ULTRIX, but without nearly so much venom. Compare {AIDX}, {HP-SUX}, {Nominal Semidestructor}, {Telerat}, {sun-stools}.

:bulletproof: /adj./ Used of an algorithm or implementation considered extremely {robust}; lossage-resistant; capable of correctly recovering from any imaginable exception condition -- a rare and valued quality. Syn. {armor-plated}.

:bum: 1. /vt./ To make highly efficient, either in time or space, often at the expense of clarity. "I managed to bum three more instructions out of that code." "I spent half the night bumming the interrupt code." In 1996, this term and the practice it describes are semi-obsolete. In {elder days}, John McCarthy (inventor of {LISP}) used to compare some efficiency-obsessed hackers among his students to "ski bums"; thus, optimization became "program bumming", and eventually just "bumming". 2. To squeeze out excess; to remove something in order to improve whatever it was removed from (without changing function; this distinguishes the process from a {featurectomy}). 3. /n./ A small change to an algorithm, program, or hardware device to make it more efficient. "This hardware bum makes the jump instruction faster." Usage: now uncommon, largely superseded by /v./ {tune} (and /n./ {tweak}, {hack}), though none of these exactly capture sense 2. All these uses are rare in Commonwealth hackish, because in the parent dialects of English `bum' is a rude synonym for `buttocks'.

:bump: /vt./ Synonym for increment. Has the same meaning as C's ++ operator. Used esp. of counter variables, pointers, and index dummies in `for', `while', and `do-while' loops.

:burble: /v./ [from Lewis Carroll's "Jabberwocky"] Like {flame}, but connotes that the source is truly clueless and ineffectual (mere flamers can be competent). A term of deep contempt. "There's some guy on the phone burbling about how he got a DISK FULL error and it's all our comm software's fault." This is mainstream slang in some parts of England.

:buried treasure: /n./ A surprising piece of code found in some program. While usually not wrong, it tends to vary from {crufty} to {bletcherous}, and has lain undiscovered only because it was functionally correct, however horrible it is. Used sarcastically, because what is found is anything *but* treasure. Buried treasure almost always needs to be dug up and removed. "I just found that the scheduler sorts its queue using {bubble sort}! Buried treasure!"

:burn-in period: /n./ 1. A factory test designed to catch systems with {marginal} components before they get out the door; the theory is that burn-in will protect customers by outwaiting the steepest part of the {bathtub curve} (see {infant mortality}). 2. A period of indeterminate length in which a person using a computer is so intensely involved in his project that he forgets basic needs such as food, drink, sleep, etc. Warning: Excessive burn-in can lead to burn-out. See {hack mode}, {larval stage}.

Historical note: the origin of "burn-in" (sense 1) is apparently the practice of setting a new-model airplane's brakes on fire, then extinguishing the fire, in order to make them hold better. This was done on the first version of the U.S. spy-plane, the U-2.

:burst page: /n./ Syn. {banner}, sense 1.

:busy-wait: /vi./ Used of human behavior, conveys that the subject is busy waiting for someone or something, intends to move instantly as soon as it shows up, and thus cannot do anything else at the moment. "Can't talk now, I'm busy-waiting till Bill gets off the phone."

Technically, `busy-wait' means to wait on an event by {spin}ning through a tight or timed-delay loop that polls for the event on each pass, as opposed to setting up an interrupt handler and continuing execution on another part of the task. This is a wasteful technique, best avoided on time-sharing systems where a busy-waiting program may {hog} the processor.

:buzz: /vi./ 1. Of a program, to run with no indication of progress and perhaps without guarantee of ever finishing; esp. said of programs thought to be executing tight loops of code. A program that is buzzing appears to be {catatonic}, but never gets out of catatonia, while a buzzing loop may eventually end of its own accord. "The program buzzes for about 10 seconds trying to sort all the names into order." See {spin}; see also {grovel}. 2. [ETA Systems] To test a wire or printed circuit trace for continuity by applying an AC rather than DC signal. Some wire faults will pass DC tests but fail a buzz test. 3. To process an array or list in sequence, doing the same thing to each element. "This loop buzzes through the tz array looking for a terminator type."

:BWQ: /B-W-Q/ /n./ [IBM: abbreviation, `Buzz Word Quotient'] The percentage of buzzwords in a speech or documents. Usually roughly proportional to {bogosity}. See {TLA}.

:by hand: /adv./ 1. Said of an operation (especially a repetitive, trivial, and/or tedious one) that ought to be performed automatically by the computer, but which a hacker instead has to step tediously through. "My mailer doesn't have a command to include the text of the message I'm replying to, so I have to do it by hand." This does not necessarily mean the speaker has to retype a copy of the message; it might refer to, say, dropping into a subshell from the mailer, making a copy of one's mailbox file, reading that into an editor, locating the top and bottom of the message in question, deleting the rest of the file, inserting `>' characters on each line, writing the file, leaving the editor, returning to the mailer, reading the file in, and later remembering to delete the file. Compare {eyeball search}. 2. By extension, writing code which does something in an explicit or low-level way for which a presupplied library routine ought to have been available. "This cretinous B-tree library doesn't supply a decent iterator, so I'm having to walk the trees by hand."

:byte:: /bi:t/ /n./ [techspeak] A unit of memory or data equal to the amount used to represent one character; on modern architectures this is usually 8 bits, but may be 9 on 36-bit machines. Some older architectures used `byte' for quantities of 6 or 7 bits, and the PDP-10 supported `bytes' that were actually bitfields of 1 to 36 bits! These usages are now obsolete, and even 9-bit bytes have become rare in the general trend toward power-of-2 word sizes.

Historical note: The term was coined by Werner Buchholz in 1956 during the early design phase for the IBM Stretch computer; originally it was described as 1 to 6 bits (typical I/O equipment of the period used 6-bit chunks of information). The move to an 8-bit byte happened in late 1956, and this size was later adopted and promulgated as a standard by the System/360. The word was coined by mutating the word `bite' so it would not be accidentally misspelled as {bit}. See also {nybble}.

:bytesexual: /bi:t`sek'shu-*l/ /adj./ Said of hardware, denotes willingness to compute or pass data in either {big-endian} or {little-endian} format (depending, presumably, on a {mode bit} somewhere). See also {NUXI problem}.

:bzzzt, wrong: /bzt rong/ /excl./ [Usenet/Internet] From a Robin Williams routine in the movie "Dead Poets Society" spoofing radio or TV quiz programs, such as *Truth or Consequences*, where an incorrect answer earns one a blast from the buzzer and condolences from the interlocutor. A way of expressing mock-rude disagreement, usually immediately following an included quote from another poster. The less abbreviated "*Bzzzzt*, wrong, but thank you for playing" is also common; capitalization and emphasis of the buzzer sound varies.

= C = =====

:C: /n./ 1. The third letter of the English alphabet. 2. ASCII 1000011. 3. The name of a programming language designed by Dennis Ritchie during the early 1970s and immediately used to reimplement {{Unix}}; so called because many features derived from an earlier compiler named `B' in commemoration of *its* parent, BCPL. (BCPL was in turn descended from an earlier Algol-derived language, CPL.) Before Bjarne Stroustrup settled the question by designing {C++}, there was a humorous debate over whether C's successor should be named `D' or `P'. C became immensely popular outside Bell Labs after about 1980 and is now the dominant language in systems and microcomputer applications programming. See also {languages of choice}, {indent style}.

C is often described, with a mixture of fondness and disdain varying according to the speaker, as "a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language".

:C Programmer's Disease: /n./ The tendency of the undisciplined C programmer to set arbitrary but supposedly generous static limits on table sizes (defined, if you're lucky, by constants in header files) rather than taking the trouble to do proper dynamic storage allocation. If an application user later needs to put 68 elements into a table of size 50, the afflicted programmer reasons that he or she can easily reset the table size to 68 (or even as much as 70, to allow for future expansion) and recompile. This gives the programmer the comfortable feeling of having made the effort to satisfy the user's (unreasonable) demands, and often affords the user multiple opportunities to explore the marvelous consequences of {fandango on core}. In severe cases of the disease, the programmer cannot comprehend why each fix of this kind seems only to further disgruntle the user.

:C++: /C'-pluhs-pluhs/ /n./ Designed by Bjarne Stroustrup of AT&T Bell Labs as a successor to {C}. Now one of the {languages of choice}, although many hackers still grumble that it is the successor to either Algol 68 or {Ada} (depending on generation), and a prime example of {second-system effect}. Almost anything that can be done in any language can be done in C++, but it requires a {language lawyer} to know what is and what is not legal-- the design is *almost* too large to hold in even hackers' heads. Much of the {cruft} results from C++'s attempt to be backward compatible with C. Stroustrup himself has said in his retrospective book "The Design and Evolution of C++" (p. 207), "Within C++, there is a much smaller and cleaner language struggling to get out." [Many hackers would now add "Yes, and it's called Java" --ESR]

:calculator: [Cambridge] /n./ Syn. for {bitty box}.

:Camel Book: /n./ Universally recognized nickname for the book "Programming Perl", by Larry Wall and Randal L. Schwartz, O'Reilly Associates 1991, ISBN 0-937175-64-1. The definitive reference on {Perl}.

:can: /vt./ To abort a job on a time-sharing system. Used esp. when the person doing the deed is an operator, as in "canned from the {{console}}". Frequently used in an imperative sense, as in "Can that print job, the LPT just popped a sprocket!" Synonymous with {gun}. It is said that the ASCII character with mnemonic CAN (0011000) was used as a kill-job character on some early OSes. Alternatively, this term may derive from mainstream slang `canned' for being laid off or fired.

:can't happen: The traditional program comment for code executed under a condition that should never be true, for example a file size computed as negative. Often, such a condition being true indicates data corruption or a faulty algorithm; it is almost always handled by emitting a fatal error message and terminating or crashing, since there is little else that can be done. Some case variant of "can't happen" is also often the text emitted if the `impossible' error actually happens! Although "can't happen" events are genuinely infrequent in production code, programmers wise enough to check for them habitually are often surprised at how frequently they are triggered during development and how many headaches checking for them turns out to head off. See also {firewall code} (sense 2).

:candygrammar: /n./ A programming-language grammar that is mostly {syntactic sugar}; the term is also a play on `candygram'. {COBOL}, Apple's Hypertalk language, and a lot of the so-called `4GL' database languages share this property. The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program. This intention comes to grief on the reality that syntax isn't what makes programming hard; it's the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that `candygrammar' languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker.

[The overtones from the old Chevy Chase skit on Saturday Night Live should not be overlooked. This was a "Jaws" parody. Someone lurking outside an apartment door tries all kinds of bogus ways to get the occupant to open up, while ominous music plays in the background. The last attempt is a half-hearted "Candygram!" When the door is opened, a shark bursts in and chomps the poor occupant. There is a moral here for those attracted to candygrammars. Note that, in many circles, pretty much the same ones who remember Monty Python sketches, all it takes is the word "Candygram!", suitably timed, to get people rolling on the floor. -- GLS]