1. <operating system, software> The sequence of states of an
	executing {program}.  A process consists of the program {code}
	(which may be shared with other processes which are executing
	the same program), private data, and the state of the
	{processor}, particularly the values in its {registers}.  It
	may have other associated resources such as a {process
	identifier}, open files, {CPU time} limits, {shared memory},
	{child processes}, and {signal handlers}.

	One process may, on some {platforms}, consist of many
	{threads}.  A {multitasking} {operating system} can run
	multiple processes {concurrently} or in {parallel}, and allows
	a process to spawn "child" processes.

	(2001-06-16)

	2. <business> The sequence of activities, people, and systems
	involved in carrying out some business or achieving some
	desired result.  E.g. software development process, project
	management process, configuration management process.

	(2001-06-16)

<software> Instructions for a computer in some programming
	language, often {machine language}.  The word "code" is often
	used to distinguish instructions from {data} (e.g. "The code
	is marked 'read-only'") whereas "{software}" is used in
	contrast with "{hardware}" and may consist of more than just
	code.

	(2000-04-08)

<mathematics> {radix}.

<object-oriented, programming> Improving a computer {program}
	by reorganising its internal structure without altering its
	external behaviour.

	When software developers add new features to a program, the
	code degrades because the original program was not designed
	with the extra features in mind.

	This problem could be solved by either rewriting the existing
	code or working around the problems which arise when adding
	the new features.  Redesigning a program is extra work, but
	not doing so would create a program which is more complicated
	than it needs to be.  Refactoring is a collection of
	techniques which have been designed to provide an alternative
	to the two situations mentioned above.

	The techniques enable programmers to restructure code so
	that the design of a program is clearer.  It also allows
	programmers to extract {reusable components}, streamline a
	program, and make additions to the program easier to
	implement.

	Refactoring is usually done by renaming {methods}, moving
	{fields} from one {class} to another, and moving code into a
	separate method.

	Although it is done using small and simple steps,
	refactoring a program will vastly improve its design and
	structure, making it easier to maintain and leading to
	more robust code.

	{"Refactoring, Reuse & Reality" by Bill Opdyke
	(http://st-www.cs.uiuc.edu/users/opdyke/wfo.990201.refac.html)}.

	{"Refactoring, a first example" by Martin Fowler
	(http://www.aw.com/cseng/titles/0-201-89542-0/vidrefact/vidrefact.html)}.

	(2001-05-02)

1. To copy {data} (often {program} {code} to be {run}) into
	{memory}, possibly {parsing} it somehow in the process.
	E.g. "{WordPerfect} can't load this {RTF} file - are you sure
	it didn't get corrupted in the {download}?"  Opposite of
	{save}.

	2. The degree to which a computer, {network}, or other
	resource is used, sometimes expressed as a percentage of the
	maximum available.  E.g. "What kind of CPU load does that
	program give?", "The network's constantly running at 100%
	load".  Sometimes used, by extension, to mean "to increase the
	level of use of a resource".  E.g. "Loading a spreadsheet
	really loads the CPU".  See also: {load balancing}.

	3. To {install} a piece of {software} onto a system.
	E.g. "The computer guy is gonna come load Excel on my laptop
	for me".  This usage is widely considered to be incorrect.

	(2002-07-02)

1. <programming> The prototype for an {object} in an
	{object-oriented language}; analogous to a {derived type} in a
	{procedural language}.  A class may also be considered to be a
	set of objects which share a common structure and behaviour.
	The structure of a class is determined by the {class
	variables} which represent the {state} of an object of that
	class and the behaviour is given by a set of {methods}
	associated with the class.

	Classes are related in a {class hierarchy}.  One class may be
	a specialisation (a "{subclass}") of another (one of its
	"{superclasses}") or it may be composed of other classes or it
	may use other classes in a {client-server} relationship.  A
	class may be an {abstract class} or a {concrete class}.

	See also {signature}.

	2. <programming> See {type class}.

	3. <networking> One of three types of {Internet addresses}
	distinguished by their most significant bits.

	3. <language> A language developed by the {Andrew Project}.
	It was one of the first attempts to add {object-oriented}
	features to {C}.

	(1995-05-01)

<file system> An element of data storage in a {file system}.

	The history of computing is rich in varied kinds of files and
	{file systems}, whether ornate (e.g., {Macintosh file system}
	for a well-known case) or deficient (e.g., many simple
	pre-1980s file systems don't allow {directories}).

	However, the prototypical file has these characteristics:

	* It is a single sequence of bytes (but consider {Macintosh}
	{resource forks}).

	* It has a finite length, unlike, e.g. a {Unix} {device}.

	* It is stored in a {non-volatile storage} medium (but see
	{ramdrive}).

	* It exists (nominally) in a {directory}.

	* It has a name that it can be referred to by in file
	operations, possibly in combination with its {path}.

	Additionally, a file system may associate other information
	with a file, such as {permission} bits or other {file
	attributes}; timestamps for file creation, last revision, and
	last access; revision numbers (a` la VMS), and other kinds of
	{magic}.

	Compare: {document}.

	(1997-04-08)

1. A discrepancy between a computed, observed, or measured
	value or condition and the true, specified, or theoretically
	correct value or condition.

	2. <programming> A mental mistake made by a programmer that
	may result in a program {fault}.

	3. (verb) What a program does when it stops as result of a
	programming error.

	(2000-03-28)

The structure of strings in some language.  A language's
	syntax is described by a {grammar}.  For example, the syntax
	of a binary number could be expressed as

		binary_number = bit [ binary_number ]

		bit = "0" | "1"

	meaning that a binary number is a bit optionally followed by a
	binary number and a bit is a literal zero or one digit.

	The meaning of the language is given by its {semantics}.

	See also {abstract syntax}, {concrete syntax}.

	(1994-10-31)

1. {application program}.

	2. {function application}.

<programming> An unwanted and unintended property of a program
	or piece of hardware, especially one that causes it to
	malfunction.  Antonym of {feature}.  E.g. "There's a bug in
	the editor: it writes things out backward."  The
	identification and removal of bugs in a program is called
	"{debugging}".

	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!

	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."

	[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]

	[{Jargon File}]

	(1999-06-29)

In {object-oriented programming} sending a message to an
	{object} (to invoke a {method}) is equivalent to calling a
	{procedure} in traditional programming languages, except that
	the actual code executed may only be selected at run time
	depending on the {class} of the object.  Thus, in response to
	the message "drawSelf", the method code invoked would be
	different if the target object were a circle or a square.

	(1995-02-16)

<computer> A machine that can be programmed to manipulate
	symbols.  Computers can perform complex and repetitive
	procedures quickly, precisely and reliably and can quickly
	store and retrieve large amounts of data.

	The physical components from which a computer is constructed
	(electronic circuits and input/output devices) are known as
	"{hardware}".  Most computers have four types of hardware
	component: CPU, input, output and memory.  The CPU ({central
	processing unit}) executes programs ("{software}") which tell
	the computer what to do.  Input and output (I/O) devices allow
	the computer to communicate with the user and the outside
	world.  There are several kinds of memory - fast, expensive,
	short term memory (e.g. {RAM}) to hold intermediate results,
	and slower, cheaper, long-term memory (e.g. {magnetic disk} and
	{magnetic tape}) to hold programs and data between jobs.

	See also {analogue computer}.

	(1995-03-10)

See {followup}.