A scripting language is a programming language that can be used to provide a programmatic interface to a running program. It allows the user of a program to script actions for the program to take, and define if/when those actions should occur. A program sporting such a mechanism is said to be scriptable.
Contrary to popular belief, what makes a programming language a scripting language has nothing to do with whether or not it can be compiled, whether or not its variables are typed or have storage classes, or whether memory can be explicitly managed, but instead indicates what role the language plays in a program. If the language is available to the user at runtime, and allows the user to direct the behaviour of the main program, then it is a scripting language for that program.
The language that a program itself is written in is called the system language, or implementation language of that program. Traditionally, languages like Tcl, Python, and Perl, have been considered scripting languages because that was the role that each of them was initially designed to play. As these languages grew in popularity, they began to be put to use as system languages; i.e., standalone applications written entirely in these languages appeared. The feature sets of these languages continued to evolve and mature, partially in response to this new-found role, making them even more attractive as system languages. Modern versions of these languages are used both as scripting languages and as system languages, and sometimes a single language fills both roles in the same program. In fact, one of the advantages of using a language like Tcl as the system language of a program is that it is then also available for use as a scripting language.
The various Unix shells are scripting languages because they provide a programmatic interface to the operating system. They strongly favour interactive use, and their syntax and semantics make them a poor choice as a system language. Very few standalone programs are written in a shell language, and those that are tend to get rewritten in a more fitting language once they reach a certain threshold of complexity.
From this perspective, Ousterhout's Dichotomy is false. A language is not fundamentally a scripting language or a system language, but rather has a feature set that makes it more or less fit for either purpose, and languages designed to fill one role can evolve to fill the other role as well. It is true, however, that languages requiring a separate explicit compilation step are almost never used as scripting languages because that extra step is too cumbersome to work into a running program.
Which languages make good scripting languages, which languages make good system languages, and why? One common trait of a scripting language is that it is designed to interact with the larger system. In the case of general scripting languages like Tcl and shells, this means making it trivially easy to invoke other programs and communicate with them via their standard I/O channels. Tcl in particular stands out in this area due to its asynchronous I/O capabiltities and EIAS data model. A foreign function interface is another feature that fills this need.
An interactive read-evaluate-print loop is another common feature of a scripting language.
Another obvious hallmark of a scripting language is that its creator calls it that. Designing a language that will interact and play well with a larger system at runtime takes some care, and languages that were not specifically designed to fill the role of a scripting language rarely end up getting used as such, although the inverse is not true at all. The exception to this may be Lisp, which was not designed specifically as a scripting language, but has had a very successful career in that role. The ability of scripting languages to do double duty as systems languages suggests that they are the more "general" category of language.
It turns out that scripting is not only useful to users of a program, but to the developers of a program itself, so that today many programs are designed somewhat like an operating system. There is a smaller "kernel" written in the system language, and much of the additional functionality is written in the scripting language.
Another interesting development is that where originally scripting languages were embedded into the main program as a sort of add-on, the advantages of programming in a scripting language have led to the consensus that it's a good strategy to write a program in a scripting language, and extend the scripting language as necessary to support the needs of the program. This leads to the observation that every possible program could be written as a Tcl extension, and many Tcl advocates would that it were so!
Javascript is interesting because although it is quite obviously a scripting language, the argument could be made that it is not a general-purpose scripting language, as it was designed as a scripting language for a specific class of systems, and is only used for that purpose. Recent developments such as node.js, however are bringing Javascript closer to being a general-purpose scripting language or as a system language.
Some scripting languages are specialized to accomplishing a particular task, and sometimes the larger program has almost no functionality other than to interpret the scripts written for them. Such languages are not fit for use as general scripting languages, but can excel in their own niche.
The following languages are rarely, if ever, used as scripting languages
Phil Ehrens wrote:
> Didn't Milton write (Paradise Regained?): > "Perl's lots of funne, but Tcl's where the work is donne"?
KBK: A test that's quite accurate for whether a language is a "scripting" language: If I have a character string that contains code written in the language, can I evaluate it readily within a running program? By this test, the LISP-like languages are also scripting languages, but many Basic implementations are not. It's not just a question of "does the language support the eval feature." Instead, the presence or absence of eval is a window into what the language designer considered important.
LV: does awk have an eval type operation? RS: Not from what I know; hence it's more on the Fortran/C side of code and (string) data strictly separated.
JMN: Apparently an ex-TCLer wrote BeanShell which has been described as "a Java source interpreter with object scripting features".
The author of BeanShell compares the relationship of Java and BeanShell to the relationship of C and Tcl/Tk. Part of the beanshell manual has some information relevant to this page: http://www.beanshell.org/manual/intro.html#Scripting_vs._Application_Languages
LES 2003-09-02: I don't think it is trivial to "interact with other programs, allowing one to trivially pass input and gather output for further processing" when using Tcl. It's been proven that running a sed one-liner from within Tcl, for example, can be very difficult maybe even impossible. Tcl messes too much with the brackets, changes backward slashes to forward slashes on its own and will escape spaces with \ on occasion. Very annoying.
Grrrr; CL says that no, that has not been proven, and, as often as not, the problem is that Tcl does not mess with special characters as naive users expect. Let's talk this over a bit more and make sure we have our stories straight.
LES retorts: http://groups.google.com/groups?th=b46ba29327d4ed2c ... or... http://dbforums.com/t878814.html (looks prettier)
You may prove it is possible, but you won't convince me it is "trivial".
US Sorry LES, I'm unable to see the problem. Your original sed line was:
sed -r -n '/# =+/{h;${x;p;};d;};H;${x;p;}' someFilePathSince single quotes are for the shell what braces are for Tcl, I tried this:
set myTail [exec sed -r -n {/# =+/{h;${x;p;};d;};H;${x;p;}} someFilePath]In my eyes it really looks like a trivial transposition. BTW, I didn't find this in the list of your frustration trials.
PWQ 2004-05-18: I would add this as a technical point. Most people confuse scripting for interpreting.
Can the langugae do this:
set fred ut
p${fred}s {Hello World}That is, Are the instructions static or dynamically computed.( The pointy heads may have a formalisim to describe the above). Eval would not meet the above criteria.
In this case I would say that only a small subset of interpreted languages are scripting. Tcl, Dbase (FoxPro et al), and unix shells are the only one that comes to mind.
Well, by definition scripting languages are languages you write scripts in. The question is: What are scripts?
Scripts are a static sequence of commands (analogy: the script to a play). But in this context, it's a static sequence of operations sent into an interpreter instead of the user having to interactively enter the commands in.
So...scripting languages are the command language supported be an (any) interactive environment, provided the commands can be sourced from a file in addition to direct user interaction. Tclsh meets this criteria. So do Unix shells, the dos batch language, perl and python. Even editor macros are often basic scripting language. Note that not all scripting languages are in fact programming languages, as they may not be turing complete.
All that said, terminology is often used loosely, and usually when people say scripting language they mean interpreted language.
FW: I kind of adhere to the idea that the technical definition of a scripting language would be a less-than-natively-compiled language with facilities designed to automate lower-level actions; sort of a format to describe the problem for lower level code to perform. In practice, this causes a paradigm where the language is made for optimum programmer versatility and ease of use. You can work in a fantasy land where everything fits together into some programming ethic, rather than a clunky language tailored to the specific vagaries of the environment. Of course, it's technically possible to write a native compiler for any language, but at a certain level of abstraction it barely gives any boost speed-wise.