<theory, programming> (Or "data type") A set of values from
	which a {variable}, {constant}, {function}, or other
	{expression} may take its value.  A type is a classification
	of data that tells the {compiler} or {interpreter} how the
	programmer intends to use it.  For example, the process and
	result of adding two variables differs greatly according to
	whether they are integers, floating point numbers, or strings.

	Types supported by most programming languages include
	{integers} (usually limited to some range so they will fit in
	one {word} of storage), {Booleans}, {floating point numbers},
	and characters.  {Strings} are also common, and are
	represented as {lists} of characters in some languages.

	If s and t are types, then so is s -> t, the type of
	{functions} from s to t; that is, give them a term of type s,
	functions of type s -> t will return a term of type t.

	Some types are {primitive} - built-in to the language, with no
	visible internal structure - e.g. Boolean; others are
	composite - constructed from one or more other types (of
	either kind) - e.g. {lists}, {arrays}, {structures}, {unions}.
	{Object-oriented programming} extends this with {classes}
	which encapsulate both the structure of a type and the
	operations that can be performed on it.

	Some languages provide {strong typing}, others allow {implicit
	type conversion} and/or {explicit type conversion}.

	(2003-12-22)

<jargon> 1. A good property or behaviour (as of a program).
	Whether it was intended or not is immaterial.

	2. An intended property or behaviour (as of a program).
	Whether it is good or not is immaterial (but if bad, it is
	also a {misfeature}).

	3. A surprising property or behaviour; in particular, one that
	is purposely inconsistent because it works better that way -
	such an inconsistency is therefore a {feature} and not a
	{bug}.  This kind of feature is sometimes called a {miswart}.

	4. A property or behaviour that is gratuitous or unnecessary,
	though perhaps also impressive or cute.  For example, one
	feature of {Common LISP}'s "format" function is the ability to
	print numbers in two different Roman-numeral formats (see
	{bells, whistles, and gongs}).

	5. A property or behaviour that was put in to help someone
	else but that happens to be in your way.

	6. A bug that has been documented.  To call something a
	feature sometimes means the author of the program did not
	consider the particular case, and that the program responded
	in a way that was unexpected but not strictly incorrect.  A
	standard joke is that a bug can be turned into a {feature}
	simply by documenting it (then theoretically no one can
	complain about it because it's in the manual), or even by
	simply declaring it to be good.  "That's not a bug, that's a
	feature!" is a common catch-phrase.  Apparently there is a
	Volkswagen Beetle in San Francisco whose license plate reads
	"FEATURE".

	See also {feetch feetch}, {creeping featurism}, {wart}, {green
	lightning}.

	The relationship among bugs, features, misfeatures, warts and
	miswarts might be clarified by the following hypothetical
	exchange between two hackers on an airliner:

	A: "This seat doesn't recline."

	B: "That's not a bug, that's a feature.  There is an emergency
	exit door built around the window behind you, and the route
	has to be kept clear."

	A: "Oh.  Then it's a misfeature; they should have increased
	the spacing between rows here."

	B: "Yes.  But if they'd increased spacing in only one section
	it would have been a wart - they would've had to make
	nonstandard-length ceiling panels to fit over the displaced
	seats."

	A: "A miswart, actually.  If they increased spacing throughout
	they'd lose several rows and a chunk out of the profit margin.
	So unequal spacing would actually be the Right Thing."

	B: "Indeed."

	"Undocumented feature" is a common euphemism for a {bug}.

	7. An attribute or function of a {class} in {Eiffel}.

	[{Jargon File}]

	(1995-10-22)

<operating system, programming> The process of carrying out
	the {instructions} in a computer program by a computer.

	See also {dry run}.

	(1996-05-13)

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)

<networking, tool> (ping, originally contrived to match
	submariners' term for the sound of a returned sonar pulse) A
	program written in 1983 by Mike Muuss (who also wrote {TTCP})
	used to test reachability of destinations by sending them one,
	or repeated, {ICMP} echo requests and waiting for replies.
	Since ping works at the {IP} level its server-side is often
	implemented entirely within the {operating system} {kernel}
	and is thus the lowest level test of whether a remote host is
	alive.  Ping will often respond even when higher level,
	{TCP}-based services cannot.

	Sadly, Mike Muuss was killed in a road accident on 2000-11-20.

	The term is also used as a verb: "Ping host X to see if it is
	up."

	The {Unix} command "ping" can be used to do this and to
	measure round-trip delays.

	The funniest use of "ping" was described in January 1991 by
	Steve Hayman on the {Usenet} group comp.sys.next.  He was
	trying to isolate a faulty cable segment on a {TCP/IP}
	{Ethernet} hooked up to a {NeXT} machine.  Using the sound
	recording feature on the NeXT, he wrote a {script} that
	repeatedly invoked ping, listened for an echo, and played back
	the recording on each returned {packet}.  This caused the
	machine to repeat, over and over, "Ping ... ping ... ping ..."
	as long as the network was up.  He turned the volume to
	maximum, ferreted through the building with one ear cocked,
	and found a faulty tee connector in no time.

	Ping did not stand for "Packet InterNet Groper", Dave Mills
	offered this {backronym} expansion some time later.

	See also {ACK}, {ENQ}, {traceroute}, {spray}.

	{The Story of the Ping Program
	(http://ftp.arl.mil/~mike/ping.html)}.

	{Unix manual page}: ping(8).

	(2005-06-22)

<database> A collection of {records} in a {relational database}.

	(1997-06-04)

<chat, messaging> Any system that allows any number of
	logged-in users to have a typed, real-time, on-line
	conversation via a {network}.

	The medium of {chat} is descended from {talk}, but the terms
	(and the media) have been distinct since at least the early
	1990s.  {talk} is prototypically for a small number of people,
	generally with no provision for {channels}.  In {chat}
	systems, however, there are many {channels} in which any
	number of people can talk; and users may send private
	(one-to-one) messages.

	Some early chat systems (in use 1998) include {IRC}, {ICQ} and
	{Palace}.  More recent alternatives include {MSN Messenger}
	and {Google Talk}.

	Chat systems have given rise to a distinctive style combining
	the immediacy of talking with all the precision (and
	verbosity) that written language entails.  It is difficult to
	communicate inflection, though conventions have arisen to help
	with this.

	The conventions of chat systems include special items of
	jargon, generally abbreviations meant to save typing, which
	are not used orally.  E.g. {BCNU}, {BBL}, {BTW}, {CUL},
	{FWIW}, {FYA}, {FYI}, {IMHO}, {OT}, {OTT}, {TNX}, {WRT},
	{WTF}, {WTH}, {<g>}, {<gr&d>}, {BBL}, {HHOK}, {NHOH}, {ROTFL},
	{AFK}, {b4}, {TTFN}, {TTYL}, {OIC}, {re}.

	Much of the chat style is identical to (and probably derived
	from) {Morse code} jargon used by ham-radio amateurs since the
	1920s, and there is, not surprisingly, some overlap with {TDD}
	jargon.  Most of the jargon was in use in {talk} systems.
	Many of these expressions are also common in {Usenet} {news}
	and {electronic mail} and some have seeped into popular
	culture, as with {emoticons}.

	The {MUD} community uses a mixture of {emoticons}, a few of
	the more natural of the old-style {talk mode} abbreviations,
	and some of the "social" list above.  In general, though,
	MUDders express a preference for typing things out in full
	rather than using abbreviations; this may be due to the
	relative youth of the MUD cultures, which tend to include many
	touch typists.  Abbreviations specific to MUDs include:
	{FOAD}, ppl (people), THX (thanks), UOK? (are you OK?).

	Some {BIFF}isms (notably the variant spelling "d00d") and
	aspects of {ASCIIbonics} appear to be passing into wider use
	among some subgroups of MUDders and are already pandemic on
	{chat} systems in general.

	See also {hakspek}.

	{Suck article "Screaming in a Vacuum"
	(http://www.suck.com/daily/96/10/23/)}.

	(2006-05-31)

<operating system> /*'l*rt/ An audible and/or visual message
	intended to inform a system's users or administrators about a
	change in the operating conditions of that system or about
	some kind of error condition.  In a {graphical user
	interface}, an alert would typically be displayed as a small
	window containing the message and a button to click to dismiss
	the window.

	(1999-03-29)

<electronics> Part of a system output presented at its input.
	Feedback may be unintended.  When used as a design feature,
	the output is usually transformed by passive components which
	attenuate it in some manner; the result is then presented at
	the system input.

	Feedback is positive or negative, depending on the sign with
	which a positive change in the original input reappears after
	transformation.  Negative feedback was invented by Black to
	stabilise {vacuum tube} amplifiers.  The behaviour becomes
	largely a function of the feedback transformation and only
	minimally a function of factors such as transistor gain which
	are imperfectly known.

	Positive feedback can lead to instability; it finds wide
	application in the construction of oscillators.

	Feedback can be used to control a system, as in {feedback
	control}.

	(1996-01-02)

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> 1. A computer; especially in the construction "foo
	box" where foo is some functional qualifier, like "graphics",
	or the name of an {operating system} (thus, "{Unix} box",
	"{MS-DOS} box", etc.)  "We preprocess the data on Unix boxes
	before handing it up to the {mainframe}."  The plural
	"{boxen}" is sometimes seen.

	2. Without qualification in an {IBM} {SNA} site, "box" refers
	specifically to an {IBM} {front-end processor}.

	[{Jargon File}]

	(1994-11-29)