Talk:Ousterhout's dichotomy

From Wikipedia, the free encyclopedia

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)

[edit] 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)