1. Executable code, especially a "pure code" portion shared
	between multiple instances of a program running in a
	{multitasking} {operating system}.

	Compare {English}.

	2. Textual material in the mainstream sense; data in ordinary
	{ASCII} or {EBCDIC} representation (see {flat ASCII}).  "Those
	are text files; you can review them using the editor."

	These two contradictory senses confuse hackers too.

	[{Jargon File}]

	(1995-03-16)

<data, database> An area of a {database} {record}, or
	{graphical user interface} {form}, into which a particular
	item of data is entered.

	Example usage: "The telephone number field is not really a
	numerical field", "Why do we need a four-digit field for the
	year?".

	A {database} {column} is the set of all instances of a given
	field from all records in a {table}.

	(1999-04-26)

The stage in the {software life-cycle} at the end of the
	development process where software is evaluated to ensure that
	it complies with the requirements.

	(1995-02-14)

[{Usenet}] 1. To duplicate a portion (or whole) of another's
	message (typically with attribution to the source) in a reply
	or followup, for clarifying the context of one's response.
	See the discussion of inclusion styles under "Hacker Writing
	Style".

	2. [{C}] "#include <disclaimer.h>" has appeared in {sig
	blocks} to refer to a notional "standard {disclaimer} file".

	[{Jargon File}]

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)

1. <networking> {e-mail address}.

	2. <networking> {Internet address}.

	3. <networking> {MAC address}.

	4. <storage, programming> An unsigned integer used to select
	one fundamental element of storage, usually known as a {word}
	from a computer's {main memory} or other storage device.  The
	{CPU} outputs addresses on its {address bus} which may be
	connected to an {address decoder}, {cache controller}, {memory
	management unit}, and other devices.

	While from a hardware point of view an address is indeed an
	integer most {strongly typed} programming languages disallow
	mixing integers and addresses, and indeed addresses of
	different data types.  This is a fine example for {syntactic
	salt}: the compiler could work without it but makes writing
	bad programs more difficult.

	(1997-07-01)

1. <mathematics> In the theory of functions, the set of
	argument values for which a {function} is defined.

	See {domain theory}.

	2. <networking> A group of computers whose {hostnames} share a
	common suffix, the "domain name".  The last component of this
	is the {top-level domain}.

	See {administrative domain}, {Domain Name System}, {fully
	qualified domain name}.

	3. {Distributed Operating Multi Access Interactive Network}.

	4. <programming> A specific phase of the {software life cycle}
	in which a developer works.  Domains define developers' and
	users' areas of responsibility and the scope of possible
	relationships between products.

	5. The subject or market in which a piece of software is
	designed to work.

	(1997-12-26)

<jargon> {Marketroid} jargon for "{software}", "{hardware}",
	"{protocol}" or something else too technical to name.

	The most flagrant abuse of this word has to be "{Windows NT}"
	(New Technology) - {Microsoft}'s attempt to make the
	incorporation of some ancient concepts into their OS sound
	like real progress.  The irony, and even the meaning, of this
	seems to be utterly lost on Microsoft whose {Windows 2000}
	start-up screen proclaims "Based on NT Technology", (meaning
	yet another version of NT, including some {Windows 95}
	features at last).

	See also: {solution}.

	(2001-06-28)

<language, World-Wide Web> (CFML) A {tag} based {markup}
	language used to create {ColdFusion} applications by embedding
	ColdFusion commands in {HTML} files.

	(1999-08-01)

<language> (Formerly "LiveScript") {Netscape}'s simple,
	cross-{platform}, {World-Wide Web} {scripting language}, only
	very vaguely related to {Java} (which is a {Sun} trademark).
	JavaScript is intimately tied to the {World-Wide Web}, and
	currently runs in only three environments - as a {server}-side
	{scripting} language, as an embedded language in
	{server-parsed HTML}, and as an embedded language run in web
	{browsers} where it is the most important part of {DHTML}.

	JavaScript has a simplified {C}-like {syntax} and is tightly
	integrated with the browser {Document Object Model}.  It is
	useful for implementing enhanced {forms}, simple web
	{database} {front-ends}, and navigation enhancements.  It is
	unusual in that the {scope} of {variables} extends throughout
	the function in which they are declared rather than the
	smallest enclosing block as in C.

	JavaScript originated from {Netscape} and, for a time, only
	their products supported it.  {Microsoft} now supports a
	work-alike which they call JScript.  The resulting
	inconsistencies make it difficult to write JavaScript that
	behaves the same in all browsers.  This could be attributed to
	the slow progress of JavaScript through the standards bodies.

	JavaScript runs "100x" slower than {C}, as it is purely
	interpreted ({Java} runs "10x" slower than C code).
	{Netscape} and allies say JavaScript is an "open standard" in
	an effort to keep {Microsoft} from monopolising web software
	as they have desktop software.  {Netscape} and {Sun} have
	co-operated to enable {Java} and JavaScript to exchange
	messages and data.

	See also {VBScript}.

	{Usenet} newsgroup: {news:comp.lang.javascript}.

	Mailing List: <majordomo@obscure.org> ("subscribe javascript"
	in body).

	(2003-04-28)

To produce something according to an {algorithm} or program or
	set of rules, or as a (possibly unintended) {side effect} of
	the execution of an algorithm or program.

	The opposite of {parse}.

	[{Jargon File}]

	(1995-06-15)

<programming> A program which executes other programs.  This
	is in contrast to a {compiler} which does not execute its
	input program (the "{source code}") but translates it into
	executable "{machine code}" (also called "{object code}")
	which is output to a file for later execution.  It may be
	possible to execute the same source code either directly by an
	interpreter or by compiling it and then executing the {machine
	code} produced.

	It takes longer to run a program under an interpreter than to
	run the compiled code but it can take less time to interpret
	it than the total required to compile and run it.  This is
	especially important when prototyping and testing code when an
	edit-interpret-debug cycle can often be much shorter than an
	edit-compile-run-debug cycle.

	Interpreting code is slower than running the compiled code
	because the interpreter must analyse each statement in the
	program each time it is executed and then perform the desired
	action whereas the compiled code just performs the action.
	This run-time analysis is known as "interpretive overhead".
	Access to variables is also slower in an interpreter because
	the mapping of identifiers to storage locations must be done
	repeatedly at run time rather than at compile time.

	There are various compromises between the development speed
	when using an interpreter and the execution speed when using a
	compiler.  Some systems (e.g. some {Lisps}) allow interpreted
	and compiled code to call each other and to share variables.
	This means that once a routine has been tested and debugged
	under the interpreter it can be compiled and thus benefit from
	faster execution while other routines are being developed.
	Many interpreters do not execute the source code as it stands
	but convert it into some more compact internal form.  For
	example, some {BASIC} interpreters replace {keywords} with
	single byte tokens which can be used to {index} into a {jump
	table}.  An interpreter might well use the same {lexical
	analyser} and {parser} as the compiler and then interpret the
	resulting {abstract syntax tree}.

	There is thus a spectrum of possibilities between interpreting
	and compiling, depending on the amount of analysis performed
	before the program is executed.  For example {Emacs Lisp} is
	compiled to "{byte-code}" which is a highly compressed and
	optimised representation of the Lisp source but is not machine
	code (and therefore not tied to any particular hardware).
	This "compiled" code is then executed (interpreted) by a {byte
	code interpreter} (itself written in {C}).  The compiled code
	in this case is {machine code} for a {virtual machine} which
	is implemented not in hardware but in the byte-code
	interpreter.

	See also {partial evaluation}.

	(1995-01-30)

1. <chat> {Unix}'s simple {talk} command and {protocol}.
	write has been largely superseded by {talk} and then {irc}.

	An enhancement, {RWP}, has been proposed.

	2. <tool> A simple {text editor} for {Windows}.

	(1998-04-28)