Ousterhout's dichotomy: Difference between revisions
No edit summary |
No edit summary |
||
| (42 intermediate revisions by 32 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Division of programming languages into system programming and scripting}} |
|||
{{multiple issues| |
|||
{{refimprove|date=May 2008}} |
{{refimprove|date=May 2008}} |
||
{{original research|date=November 2010}} |
{{original research|date=November 2010}} |
||
}} |
|||
| ⚫ | '''Ousterhout's dichotomy''' is [[computer scientist]] [[John Ousterhout]]'s |
||
| ⚫ | '''Ousterhout's dichotomy''' is [[computer scientist]] [[John Ousterhout]]'s categorization<ref>{{cite web |url=https://web.stanford.edu/~ouster/cgi-bin/papers/scripting.pdf |title=Scripting: Higher Level Programming for the 21st Century |access-date=March 27, 2020 |author=Ousterhout, John |date= March 1998|work=IEEE Computer magazine }}</ref> that [[high-level programming language]]s tend to fall into two groups, each with distinct properties and uses: ''[[system programming]] languages'' and ''[[scripting language]]s'' – compare [[programming in the large and programming in the small]]. |
||
System programming languages (or ''applications languages'') usually have the following properties: |
System programming languages (or ''applications languages'') usually have the following properties: |
||
| Line 8: | Line 12: | ||
* Programs in them are compiled into [[machine code]] |
* Programs in them are compiled into [[machine code]] |
||
* Programs in them are meant to operate largely independently of other programs |
* Programs in them are meant to operate largely independently of other programs |
||
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 (programming language)|C]] and [[Modula-2]]. |
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 (programming language)|C]], [[OCaml]] and [[Modula-2]]. |
||
By contrast, scripting languages (or ''glue |
By contrast, scripting languages (or ''[[glue language]]s'') tend to have the following properties: |
||
* They are [[dynamic typing|typed dynamically]] |
* They are [[dynamic typing|typed dynamically]] |
||
* They have little or no provision for complex data structures |
* They have little or no provision for complex data structures |
||
* Programs in them (''scripts'') are [[interpreter (computing)|interpreted]] |
* Programs in them (''scripts'') are [[interpreter (computing)|interpreted]] |
||
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 |
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. Hence, 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 [[Python (programming language)|Python]], [[AppleScript]], [[C shell]], [[DOS]] [[batch file]]s, and [[Tcl]]. |
||
Ousterhout's dichotomy underlies the design of his language [[Tcl]]. |
|||
| ⚫ | |||
==History== |
|||
The dichotomy was fully set out in {{Harvtxt|Ousterhout|1998}}, though Ousterhout had drawn this distinction since at least the design of Tcl (1988), and had stated it publicly at various times. An early episode was "[http://www.vanderburg.org/OldPages/Tcl/war/ The Tcl War]" of late September and October 1994, where [[Richard Stallman]] posted an article critical of Tcl, entitled "Why you should not use Tcl",<ref>{{cite newsgroup |title=Why you should not use Tcl |last=Stallman |first=Richard |date=1994-09-23 |newsgroup=comp.lang.tcl |message-id=9409232314.AA29957@mole.gnu.ai.mit.edu |url=https://groups.google.com/d/msg/comp.lang.tcl/7JXGt-Uxqag/3JBTj5I43yAJ |access-date=2015-09-13}}</ref> to which Ousterhout replied with an articulation of his dichotomy:<ref>{{cite newsgroup |title=Re: Why you should not use Tcl |last=Ousterhout |first=John |date=1994-09-26 |newsgroup=comp.lang.tcl |message-id=367307$1un@engnews2.Eng.Sun.COM |url=https://groups.google.com/d/msg/comp.lang.tcl/7JXGt-Uxqag/vQNLEgvjmWsJ |access-date=2015-09-13}}</ref> |
|||
{{quotation| |
|||
I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.}} |
|||
==Criticism== |
|||
| ⚫ | Critics believe that the dichotomy is highly arbitrary, and refer to it as ''Ousterhout's fallacy'' or ''Ousterhout's false dichotomy''.<ref>{{cite AV media |people=Stuart Halloway |url=https://www.youtube.com/watch?v=KZ8u_sWT9Ls | archive-url=https://web.archive.org/web/20180117182251/https://www.youtube.com/watch?v=KZ8u_sWT9Ls| archive-date=2018-01-17 | url-status=dead|title=Osterhout's Dichotomy Isn't}}</ref> While static-versus-dynamic typing, data structure complexity, and dependent versus stand-alone might be said to be unrelated features, the usual critique of Ousterhout's dichotomy is of its distinction of compiling versus interpreting. Neither semantics nor syntax depend significantly on whether a language implementation compiles into machine language, interprets, tokenizes, or byte-compiles at the start of each run, or any mix of these. In addition, basically no languages in widespread use are purely interpreted without a compiler; this makes compiling versus interpreting a dubious parameter in a taxonomy of programming languages.<ref>{{FOLDOC|Ousterhout%27s+dichotomy}}</ref> |
||
==References== |
==References== |
||
{{Reflist}} |
|||
{{reflist}} |
|||
==Further reading== |
==Further reading== |
||
*{{cite journal|last=Kumar|first=Deepak|date=September 2010|title=Reflections: language wars and false dichotomies|journal=ACM Inroads|volume=1|issue=3|url=http://portal.acm.org/citation.cfm?id=1835431}} |
*{{cite journal|last=Kumar|first=Deepak|date=September 2010|title=Reflections: language wars and false dichotomies|journal=ACM Inroads|volume=1|issue=3|pages=10–11|doi=10.1145/1835428.1835431|s2cid=34789810|url=http://portal.acm.org/citation.cfm?id=1835431}} |
||
*{{cite journal|last=Grover|first=Andy|title=Become a better programmer by bridging Ousterhout's Dichotomy|journal= |
*{{cite journal|last=Grover|first=Andy|title=Become a better programmer by bridging Ousterhout's Dichotomy|journal=Open Source Bridge|date=19 June 2009|url=http://www.slideshare.net/guest2838a0/bridging-ousterhouts-dichotomy}} |
||
*{{cite web|url=http://www.devx.com/Java/Article/7866/1763?supportItem=4|title=Build a Reflection-based Interpreter in Java (Sidebar: Scripting vs. Programming)|last=Travis|first=Greg|date=October 21, 2002|work=DevX|accessdate=2010-11-08}} |
|||
==External links== |
==External links== |
||
*[http://wiki.tcl.tk/9865 Ousterhout's dichotomy] at the [[Tcl]] [[wiki]] |
*[http://wiki.tcl.tk/9865 Ousterhout's dichotomy] at the [[Tcl]] [[wiki]] |
||
[[Category: |
[[Category:Programming language folklore]] |
||
[[Category:Software engineering folklore]] |
|||
[[Category:Programming paradigms]] |
[[Category:Programming paradigms]] |
||
[[Category:Dichotomies]] |
[[Category:Dichotomies]] |
||
[[Category:1988 in computing]] |
|||
[[es:Dicotomía de Ousterhout]] |
|||
Latest revision as of 07:35, 9 December 2024
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Ousterhout's dichotomy is computer scientist John Ousterhout's categorization[1] that high-level programming languages tend to fall into two groups, each with distinct properties and uses: system programming languages and scripting languages – compare programming in the large and programming in the small.
System programming languages (or applications languages) usually have the following properties:
- They are typed statically
- They support creating complex data structures
- Programs in them are compiled into machine code
- Programs in them are meant to operate largely independently of other programs
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, OCaml and Modula-2.
By contrast, scripting languages (or glue languages) tend to have the following properties:
- They are typed dynamically
- They have little or no provision for complex data structures
- Programs in them (scripts) are interpreted
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. Hence, 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 Python, AppleScript, C shell, DOS batch files, and Tcl.
Ousterhout's dichotomy underlies the design of his language Tcl.
History
[edit]The dichotomy was fully set out in Ousterhout (1998), though Ousterhout had drawn this distinction since at least the design of Tcl (1988), and had stated it publicly at various times. An early episode was "The Tcl War" of late September and October 1994, where Richard Stallman posted an article critical of Tcl, entitled "Why you should not use Tcl",[2] to which Ousterhout replied with an articulation of his dichotomy:[3]
I think that Stallman's objections to Tcl may stem largely from one aspect of Tcl's design that he either doesn't understand or doesn't agree with. This is the proposition that you should use *two* languages for a large software system: one, such as C or C++, for manipulating the complex internal data structures where performance is key, and another, such as Tcl, for writing small-ish scripts that tie together the C pieces and are used for extensions.
Criticism
[edit]Critics believe that the dichotomy is highly arbitrary, and refer to it as Ousterhout's fallacy or Ousterhout's false dichotomy.[4] While static-versus-dynamic typing, data structure complexity, and dependent versus stand-alone might be said to be unrelated features, the usual critique of Ousterhout's dichotomy is of its distinction of compiling versus interpreting. Neither semantics nor syntax depend significantly on whether a language implementation compiles into machine language, interprets, tokenizes, or byte-compiles at the start of each run, or any mix of these. In addition, basically no languages in widespread use are purely interpreted without a compiler; this makes compiling versus interpreting a dubious parameter in a taxonomy of programming languages.[5]
References
[edit]- ^ Ousterhout, John (March 1998). "Scripting: Higher Level Programming for the 21st Century" (PDF). IEEE Computer magazine. Retrieved March 27, 2020.
- ^ Stallman, Richard (1994-09-23). "Why you should not use Tcl". Newsgroup: comp.lang.tcl. Usenet: 9409232314.AA29957@mole.gnu.ai.mit.edu. Retrieved 2015-09-13.
- ^ Ousterhout, John (1994-09-26). "Re: Why you should not use Tcl". Newsgroup: comp.lang.tcl. Usenet: 367307$1un@engnews2.Eng.Sun.COM. Retrieved 2015-09-13.
- ^ Stuart Halloway. Osterhout's Dichotomy Isn't. Archived from the original on 2018-01-17.
- ^ This article is based on material taken from Ousterhout%27s+dichotomy at the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.
Further reading
[edit]- Kumar, Deepak (September 2010). "Reflections: language wars and false dichotomies". ACM Inroads. 1 (3): 10–11. doi:10.1145/1835428.1835431. S2CID 34789810.
- Grover, Andy (19 June 2009). "Become a better programmer by bridging Ousterhout's Dichotomy". Open Source Bridge.
External links
[edit]- Ousterhout's dichotomy at the Tcl wiki