Definition of a scripting language

Here is an interesting and relevant discussion about programming language design, copied from the newsgroup "comp.compilers", starting in March 1995 and still going in July!

The discussion is interesting for various reasons:

My comments and explanations are in italics; I have edited the messages to remove some simple spelling and grammar mistakes; [...] indicates text removed or replaced (by me or others) to focus on language design. Indented text is a quote from a previous message.

Ariel Lieberman ( asked

I'm looking for a definition of a scripting language (Perl, REXX, Tcl, etc.). What are the differences between a scripting language and a "regular" programming language (C, C++, Ada, Smalltalk, etc.).

And the moderator replied

A scripting language is one in which people think they're writing scripts, and a programming language is one in which they think they're writing programs. You can come up with rules of thumb, e.g. scripting languages tend to be interpreted, but it's easy to find exceptions to any of them.

This is essentially true, and I expected the discussion to die out. However, as the next post showed, it is interesting and useful to try to come up with some rules, even if they can only be guidelines rather than a strict classification, and even though there are still gaping holes in this "definition". In particular, it bases its concept of a scripting language on the concept of a command language, although they are also essentially programming languages; when does a CLI become a shell, and when does a shell become a scripting language?

Stavros Macrakis ( replied

Scripting languages support doing programmatically what otherwise is done directly by the user through direct commands (whether textual or graphical).

Several characteristics follow from this definition.

Some command languages (e.g. Unix sh or csh command languages) are also useful as scripting languages. Some scripting languages can be used instead of a command shell. Some programming languages can easily be used as scripting languages (with appropriate libraries).

In my opinion, it is a bad idea to distinguish sharply between the design of scripting languages and the design of other programming languages. What starts out as a small script may develop over time into a very sophisticated program. Users may wish to share independently-maintained modules between scripts -- hence a need for namespace control and clear interface definition. Error handling may become necessary -- hence a need for exception handling. Cooperation among asynchronous processes may be necessary -- hence a need for threads or continuations and their related synchronization mechanisms. In short, many of the same problems that face programmers in general face script programmers in particular.

and the moderator added

I suppose one might draw the line by saying that a scripting language is one where the main effect of a program is to drive another system, while in a programming language the program itself is the main action.

to which (Jonathan Eifrig) responded

pointing out that this line is just as illusory

Of course, "traditional" programs are nothing more than scripts for a microprocessor. :-)
Ultimately, these sorts of distinctions aren't very helpful; at best they can be descriptive, not prescriptive.

Personally, I view a language as a "scripting" language if

  1. whitespace is significant, and
  2. there is an anti-quotation facility to turn strings into programs.
Both are horrid features, and both are amply found in sh, perl, and Tk. :-)

That drew a response from the designer of Perl, a complex (in the best sense of the word) scripting language, who pointed out ambiguities in Jonathan's definition (Larry Wall) responded

1. whitespace is significant
According to this criterion, Fortran was the last great scripting language. :-)

e.g. (based on punched cards) columns 1 to 6 and 73 to 80 have special meanings and newlines usually separate statements in (pre 1990) Fortran. However, spaces in the middle of Fortran identifiers are ignored.

Whitespace is significant in nearly all modern languages. You can't put whitespace inside a token in C, Ada, Modula, Lisp, Perl, etc. And you typically *must* put whitespace between two adjacent alphanumeric tokens in any of these languages.

Now, if what you meant is that newlines have syntactic meaning in addition to their ordinary whitespace meaning, I'll grant you that many languages do this, including sh, awk, Tcl and Python. But not Perl. Perl doesn't even care if you put a newline inside a literal string. Please tar Perl with a different brush.

2. there is an anti-quotation facility to turn strings into programs.
By this definition all computer languages are scripts. Of course, some "anti-quotation facilities" are clunkier than others...

e.g. if we are desperate enough, we can output some text, compile and run it.

[...] The question of "scripts" vs "programs" comes up frequently in the comp.lang.perl newsgroup.
Speaking as a computer scientist, my answer is: These are not (yet) technical terms.
Speaking as a linguist, my answer is: These words (like most words) are defined by prototype, not by boundary. A script is what you give the actors, and a program is what you give the audience. (Jonathan Eifrig) then clarified the first point from his previous post

Perhaps I should have been more clear: what I meant was that in most scripting languages, sequences of "whitespace" characters (which normally include SPACE, TAB, and NEWLINE) are not equivalent. Which means, or course, that such "whitespace" isn't really "white" at all, since there is semantic meaning attached to the various forms of "whitespace" in the program, other than the usual use of tokenization.

C doesn't escape such cruftiness either, unfortunately: "\<NEWLINE>" is not the same as "\<SPACE><NEWLINE>", and the fact that preprocessor directives must start in column 1 means that the newline character isn't really "white" at all. An unfortunate legacy of the preprocessor.

and (Peter Ludemann) responded

I think that ANSI-C allows white space before "#" for preprocessor directives. Anyway, as far as I know, there's no reason to have "\<SPACE><NEWLINE>" as different from "\<NEWLINE>" ... in fact, the C compilers for the IBM mainframe and AS/400 treat these as the same (they have to: many source files have fixed-length records).

Another example of "white space" not being white is in "make": the commands have to be preceded by a tab, which is not equivalent to spaces. Again, there's no good reason for this, except perhaps maintaining some strange kind of compatibility with the early implementations.

The discussion now rapidly increased in volume and changed emphasis, focussing mainly on the two main uses of white space other than as a word separator: