Ousterhout's dichotomy

related topics
{system, computer, user}
{language, word, form}
{math, number, function}
{law, state, case}

Ousterhout's dichotomy is computer scientist John Ousterhout's claim[1] that high-level programming languages tend to fall into two groups, each with distinct properties and uses: "system programming languages" and "scripting languages". This distinction underlies the design of his language Tcl.

System programming languages (or "applications languages") usually have the following properties:

System programming languages tend to be used for components and applications with large amounts of internal functionality such as operating systems, database servers, and Web browsers. These applications typically employ complex algorithms and data structures and require high performance. Prototypical examples of system programming languages include C and Modula-2.

By contrast, scripting languages (or "glue languages") tend to have the following properties:

Scripting languages tend to be used for applications where most of the functionality comes from other programs (often implemented in system programming languages); the scripts are used to "glue" together other programs or add additional layers of functionality on top of existing programs. Ousterhout claims that scripts tend to be short and are often written by less sophisticated programmers, so execution efficiency is less important than simplicity and ease of interaction with other programs. Common applications for scripting include Web page generation, report generation, graphical user interfaces, and system administration. Prototypical examples of scripting languages include AppleScript, C Shell, DOS batch files, and Tcl.

Many believe that the dichotomy is highly arbitrary, and refer to it as "Ousterhout's fallacy" or "Ousterhout's false dichotomy". While strong-versus-weak typing, data structure complexity, and independent versus stand-alone might be said to be unrelated features, the usual critique of Ousterhout's dichotomy is of its distinction of compilation versus interpretation, since neither semantics nor syntax depend significantly on whether code is compiled into machine-language, interpreted, tokenized, or byte-compiled at the start of each run, or any mixture of these. Many languages fall between being interpreted or compiled (e.g. Lisp, Forth, UCSD Pascal, Perl, and Java). This makes compilation versus interpretation a dubious parameter in a taxonomy of programming languages.

References

Further reading

Full article ▸

related documents
Kibibyte
PowerBASIC
Instruction register
AutoCAD DXF
UMSDOS
ANSI C
Automatic data processing
Rock Ridge
Password authentication protocol
BitchX
Data stream
VisiCalc
Grid network
Application Configuration Access Protocol
JOSS
Longitudinal redundancy check
Gnuplot
Data processing
Off-the-air
IBM 604
Common Intermediate Language
Basic serving arrangement
Klez (computer worm)
Reverse Address Resolution Protocol
XyWrite
Zinf
Wikipedia:Federal Standard 1037C terms/telecommunications encryption terms
Terabyte
Inverter (logic gate)
Teleconference