Talk:Ousterhout's dichotomy

Please Delete: Confused & Original Research

This page is based off of only one (primary) source (in the IEEE magazine, but not their scientific journal). Does Wikipedia really support having pages for primary and low impact magazine articles?

Moreover, it include a significant amount of research not in the original article viz. Java is compiled to machine code. What? In fact, it compiles to object code (bytecode). But, so does Perl, Ruby (as of 1.9), and Python. How do any of the 'scripting languages' mentioned not support advanced data structures? Perl, Ruby, and Python all support any data structure that you can contrive in C. All of these are falsely implied by the example languages (for scripting and systems) and are in contradict the original paper.

Finally, this page has been cited as having problems since 2008 and hasn't been fixed (because it wouldn't be an article if the problems were removed).

This needs to be removed.

Redundant

This page is largely redundant with System programming language. One of these should be assimilated into the other. --FOo 03:13, 4 May 2004 (UTC)

Transparency is the key property of "scripting languages"

The main article misses the key property of a good scripting language. Traditional programs use powerful abstractions to accomplish their purposes efficiently. Unfortunately they are then opaque to non-programmers, and even experienced programmers may need to study a well-written program for some time before attempting a modification. Scripting languages are intended to be easily understood by people of little programming skill and with little study. Scripts should only use a few powerful built-in abstractions, like hashed arrays. Anything fancy should be passed off to separate programs or be implemented in a host program (with the scripting system as an extension layer). In this way, Scripting allows for easy customization and extension of program functionality. Scripting language's limitations are actually liberating. Attempts to make scripting languages more powerful are counter-productive. Use deep languages for core functionality. Use scripting languages for extention, configuration, user interface, glue, etc. Tcl exhibits this concept of scripting language particularly well. Most other so-called scripting languages are really rapid prototyping languages intended for people with full programming skills. Jgd 23:26, 7 Jul 2004 (UTC)

That is because the article is about Oustershout's dichtomy which was written down in the early 80's. It is severly outdated and it can't be used to cathegorize programming languages. Eric B. and Rakim 21:19, 2 Nov 2004 (UTC)

"Can't be used to categorize programming languages." Seems a little extreme. Obviously few distinctions can be made hard and fast, but without the ability to make distinctions, we can know nothing. Languages like Python, Perl and, yes, Tcl share a lot of qualities, and are used in similar ways. One could use them to develop large scale projects -- Python especially -- but one pays for their versatility and portability; likewise, you COULD use C to glue two programs together, but would you really want to? That a grey area exists between these two extremes doesn't automatically invalidate the distinction. Solemnavalanche 05:11, 11 April 2006 (UTC)

Okay, here's a question. What are you really trying to categorize?

• Original intent of the author?
• Language features?
• Most common uses?

If you're working from original intent -- Tcl is a "scripting language" because its author said he wanted to make one -- then Perl is one, but Python is not.

If you're working from language features, which ones? Glue? Python doesn't have syntactic support for glue the way Perl does (e.g. Perl `backticks`) -- if you want to do glue in Python, you have to use method calls just as in Java.

If you're working from common uses, well, I would propose that even Perl quit being a scripting language when CGI came along. :)

My point is that the terminology (a) is too overloaded for today, and (b) was ALWAYS an oversimplification. It was a description of conditions that obtained on Unix systems of a particular era, when only C was taken seriously as a "system" or applications language, and "scripting" languages were those that were used as improvements over shell scripting.

Those conditions no longer obtain today. There are not only more languages; there are languages which strike different balances ... and which therefore do not fit in the old categories. Python does not fit neatly in either the role of C in the old Unix days, or in the role of sh or Tcl. Neither does Ruby. Lisp always baffled Unix-heads somewhat because it was neither C nor a scripting language. Perl was first created as a scripting language, but that changed when CGI came along; these days there's even a native-code compiler for it. Java is a whole 'nother kettle of toads, striking a balance somewhere between C and Lisp.

Trying to force all these things into the narrow categories "scripting language" and "systems language" would be like trying to categorize all planets as either rocks or gas. It would make sense to call Pluto a rock and Uranus a gas ... but what of Earth or Venus? --FOo 07:33, 11 April 2006 (UTC)

Wikipedia sucks

Include, include, include! What the hell is Wikipedia's fascination with that word? It appears three times in this short article and is present in practically every other article as well, and is almost always misused. ----93.106.130.136 (talk) 10:43, 28 June 2009 (UTC)

Ousterhout's dichotomy exists

Ousterhout's dichotomy is a known concept in the programming community, and maybe in computer science. It makes sense for Wikipedia to have information on it, in some form, so that people who do not know about it can look it up and see what it is. The material in this article explains what it is fairly well, even if the information is a bit dated, and there are some weak spots. As far as being original research, the explanation has been expounded upon, but not greatly. Jerryobject (talk) 09:34, 6 November 2010 (UTC)