Scripting Language
Scripting LanguageThe origin of the term was similar to its meaning in "a movie script tells actors what to do": a scripting language controlled the operation of a normally-interactive program, giving it a sequence of work to do all in one batch. For instance, one could put a series of editing commands in a file, and tell an editor to run that "script" as if those commands had been typed interactively.
This usage was generalized under Unix to describe scripts for the shell to execute, which meant that the running of a whole series of programs was controlled, not just one. Thus "shell script".
As programmable features of shells became more and more powerful (BourneShell, CeeShell), they began to resemble traditional interpreted languages such as Lisp (or perhaps Basic is a better comparison), which had never been previously called ScriptingLanguages.
Because of this evolution, more recent usage has changed the current definition to be much fuzzier, but "scripting languages" generally have these properties:
Similarly LispLanguage is still not usually called a ScriptingLanguage, but the elisp dialect's purpose in life is to script the EmacsEditor, so it could certainly be called a ScriptingLanguage.
Examples
Resources
Lua comes in two flavours. As an extension language to C it's a non-scripting language. When put inside a minimal shell and run separately it's a scripting language.
To get some data for this discussion, let's score various languages as to their "scriptness" factor. Here are the languages I use - add your language if it's not there, add your score, 0 being non-script, 9 being script, and let's keep the list in reasonable order by average. Of course, this may be of no value, but I think it might be interesting. Comments supporting non-obvious scores can be added below.
I notice that, while AssemblyLanguage and other "low-level" languages are in the list, ForthLanguage is not. It should be fairly straightforward to script using ForthLanguage. It is, at its base, an interpreted language, thus a reasonable candidate for scripting. Add to this that as far back as DOS 5.0 there have been versions of Forth that allowed passing a sequence of ForthWords? in the command line invocation (rather like, e.g. sed or awk). While most users have probably never entertained the idea of ForthScripts?, it seems quite viable as a concept. -- GarryHamilton
SmalltalkLanguage has all of the above, and it is not usually considered a scripting language. It didn't let you map external components to the semantics of the builtin types until the last third of its life, however. And source code is optional for most modern Smalltalks, though usually present in production systems.
I think you are describing secondary characteristics here. What is the real definition? Why couldn't I use Pascal as a scripting language? -- RalphJohnson
Because Pascal has strong typing, can't generate code and has a compile/link phase.
I tend to think of the SmalltalkLanguage as not being a scripting language because Smalltalk is a complete development and operation environment; individual pieces don't normally run independently. Like, in the middle of some non-Smalltalk GUI application, how could you execute a small piece of Smalltalk code to tie together some widgets?
Within the Smalltalk environment, blocks of code often do operate as a scripting language. But outside they don't. -- JeffGrigg
But you could write a smalltalk program to run independently ... -- SomeoneElse
But an independent executable is not a script. You can read a script. -- JeffGrigg
A technical definition:
In Unix, a script is a text file beginning with the line "#!" <full-path-to-interpreter> <space> <optional-flags>. not true, this is only if you want the script to be directly executable. A shell script without #! that is executed by passing its filename to sh is as much a shell script as one with #! The "interpreter" must be a program that accepts "<optional-flags> <text-file>" as command line arguments, ignores the first line, and does something sensible with the contents -- like "executing" it.
''Hmm. ocamlc generates byte-code files with the line #!/usr/bin/ocamlrun on the first line. I wouldn't consider ObjectiveCaml a scripting language just because of this. Maybe it is a necessary requirement, but it is not enough to make a language qualify as a ScriptingLanguage.''
Awk, perl, python, tcl, all shells, and some other executable programs can be used successfully as interpreters of these "script files."
In Windows, an "Active-X Scripting Language" is a ComComponent that is registered properly and supports the appropriate interfaces for receiving and executing short source code "scripts."
A creative programmer could probably turn any language into a "scripting language" by doing a compile/link when needed (or loading source into a predefined image). But there is a difference between a creative and unusual implementation, and the normal intended use of a language. -- JeffGrigg
Why should a scripting language have 'Support for object orientation'? In fact, in most scripting languages with support for OO it is quite visible that OO was added late. -- MarkoSchulz
Awk is a scripting language that has neither object-orientation nor a powerful iteration construct.
Hey, wait-a-minute -- awk programs have an implicit "powerful iteration construct": the entire script is applied to EVERY LINE of an input file.
I don't really believe that VbClassic (legacy VisualBasic) is a scripting language. (Does a scripting language require an IDE? Perhaps a visual scripting language is an oxymoron?)
I believe that the ability to generate new code within a running process and execute it may be fundamental. This ties in naturally with the presence of the language parser at runtime (e.g. consider a Python/Perl "eval" style operator.) Many Unix scripting languages though would just run another interpreter process and pass in variables set on the command line and pick up output from stdout. I seem to remember this being done in csh with backticks.
Aside: The notion of a script as something stand-alone that you can just read ties in neatly with "the PowerOfPlainText" as discussed in ThePragmaticProgrammer.
VB probably does not qualify as a scripting language, but VbScript and VisualBasicForApplications (VBA) would.
A scripting language is used to coordinate and combine components that are written in some other language and cannot usually itself be used for writing those components.
Some scripting languages, such as Python, do not require source code to be present at run time. But some would argue that such languages are not being used as "scripting languages" in that case.
To describe what a scripting language is, one should describe what a "script" is. Here's an attempt: a "script" is a user-readable and user-modifiable program that performs simple operations or that controls the operation of other programs. A "scripting language" is a programming language designed for writing scripts.
Almost any programming language could be used as a scripting language, but many are not well suited to the user-readable/user-modifiable requirement, and are not easily used to control other programs. Conversely, almost any language designed for scripting could be used to develop a standalone application, but many such languages prove inadequate as the complexity of the application increases.
I've seen a lot of Perl and Python programs that I would not consider to be "scripts". That doesn't mean that Perl and Python aren't scripting languages, just that they have advanced capabilities in addition to their scripting duties.
In the "Good Old Days," the scripting language was JobControlLanguage. It's sometimes known as "IBM's supremely rude job control language." It nicely describes the "classical" use of scripting.
The point was that you had "systems programming" languages like FORTRAN, COBOL, PL/I, and the likes. (Ada, C++, C, and such weren't typically available, but are certainly sufficiently analogous.) You'd do the "real programming" in the "systems programming" language. And then write a JCL script to control actually running the program. The "real code" would not, for instance, point to file names, but rather to some sort of "file descriptor". The JCL would be used to connect the "file descriptor" to a real file.
JCL had a complete absence of data structures and such; it was completely separate from the "real program".
Later in history, IBM introduced EXEC2, which provided a "less supremely rude" syntax. Still later, REXX came along, providing a "scripting language" with syntax resembling that of PL/I that had a rich enough set of control structures and data structures that it could be used itself for many of the things that would traditionally require a "systems programming language".
The progression on Unix that led to the creation of Perl was not dissimilar; the notable difference being that there never was anything as rude as JCL...
http://www.catb.org/~esr/jargon/html/J/JCL.html
IMO it seems odd to refer to JobControlLanguage as a "scripting language", and COBOL, etc. as "systems programming languages". JCL was never really a language (in spite of its name) - it has 3 verbs (JOB, EXEC and DD), and over 100 operands. Its only function is to specify run-time information that you don't want in the application code. I would refer to COBOL, etc., as "application programming languages" - the main "systems programming language" on mainframes is Assembler, although people often use EXEC2 and REXX for (small) "systems programming" type jobs. I do agree that REXX is a scripting language (and EXEC2 before it), but the only similarity with PL/I that I can think of is the comment convention - even statement continuation is done differently. REXX really arose out of a desire to have a more friendly EXEC2 (MikeCowlishaw, hope you agree). One very powerful feature that it introduced is SUBCOM environments, that can be used to drive different command-oriented languages from a REXX program.
IBM Research did a study some years ago, and found that a high proportion of their computing cycles were being used to execute EXEC language scripts. There seems to be some kind of reluctance to starting to work on a (simple?) job in a non-scripting language - but once one gets started (using a scripting language), it develops its own momentum... GettingOverTheHump. -- PaulMorrison
If they redid that today, they would probably find that most cycles go to managing GUI's and mouses. Progress is not without costs. The AbstractionTax?.
Can we accurately say that there are ScriptingLanguages and non-scripting languages? The properties listed at the top of this page are excellent indicators of scriptingness, but languages fall at various points on the continuum of scriptingness. VbScript is almost a pure scripting language, while PerlLanguage and PythonLanguage support more substantial programming so well they might be considered halfway between ScriptingLanguage and other kinds of languages. There are aspects of VisualBasic that have a bit of scripting-nature, but I don't consider it much of a ScriptingLanguage at all, maybe 10%.
One other clue as to a languages scriptingness is whether or not it has the word "script" in its name. -- MarkSchumann
The line between "system" and "scripting" language is very blurry. For example, the game Quake3 uses interpreted C as a scripting language. Quake3 can use the same scripts if they have been compiled and linked into a DLL.
What used to be the main visible differentiator, interpreted versus compiled, is now a side issue - today, we've got everything from interpreted system languages to compiled (compilable) scripting languages. The underlying force remains, which is that there is a market for both languages which focus on a low overhead for the programmer on small programs (scripting languages), and for languages which focus on scalability to larger programs and teams (system languages). All else are, IMHO, secondary characteristics that follow from the needs of these markets. -- FalkBruegmann
I think that much of what has been said above about ScriptingLanguage applies to InterpretedLanguage as it compares to a CompiledLanguage?. A ScriptingLanguage is a distinction in purpose, which may have profound effects on the syntax of some languages, or no effect at all on some others.
A ScriptingLanguage is any language in which the source text can be executed by an interpreter program, which does not create and then run a binary executable. I have in my possession a Pascal compiler, and a Pascal interpreter. 99.99% Same syntax, different purposes. The compiled form is used for creating redistributable binaries, the scripted form is used for creating redistributable scripts in text form. Scripts are usually kept simpler, smaller, and less complicated, but that is not always true. Scripts may be all in one file, or may bring in files from a series of subdirectories, such as Python scripts, with their modules in subdirectories. See my topics IncrementalMethod and InterpretedLanguage for more on this train of thought. WPostma.
For me, a ScriptingLanguage is something I use when I need to create a program to run once and only once. Sometimes, I subsequently discover that, in fact, I (or people around me) use it more than once. Sometimes, I and my community discover that we use it a lot, and that it often gets used with other similar tools. Sometimes, a tool made from a ScriptingLanguage is rewritten into another language. Sometimes this rewrite proves more difficult than anticipated. In some shops, the original tool is called a "prototype", because it is written in a ScriptingLanguage. Sometimes, a developer or development team learns that the ScriptingLanguage is, in fact, better at creating a specific tool or prototype than the language chosen to rewrite it in.
The most common failure I've seen in helping development shops sort out system problems has been the failure to recognize that today's ScriptingLanguage prototype is accidently and unintentionally wired into tomorrow's production system (cf. RunDLL.dll).
I have used Emacs and MockLisp as a ScriptingLanguage. I have worked with many developers whose primary use of Unix was as a runtime support system for their ScriptingLanguage of choice, whether it be Perl, AWK, CSH, KSH, etc. I find that SmalltalkLanguage is my favorite ScriptingLanguage, because I am more proficient at expressing what I want the machine to do using that language, and because the resulting code more readily survives the occasional transition into a production environment. I have heard rumors that Perl is similar, but my experience with Perl (in the life sciences and biopharm domains) does not support such rumor.
See Scripting Patterns at http://www-dse.doc.ic.ac.uk/~np2/patterns/scripting/ (BrokenLink, use http://web.archive.org/web/20041010125419/www.doc.ic.ac.uk/~np2/patterns/scripting/)
Has anybody ever heard about an InterpreterInAnInterpreter? (one ScriptingLanguage interpreter running in another ScriptingLanguage)? I'm currently into writing such a thing, just curious if there is already such a thing anywhere. -- MarioSalzer?
Oh yes; in the context of Lisp, more has been written about this than could possibly be cited. If you said "compiler", then BootStrapping would apply.
See in particular MetaCircularEvaluator (and the related HomoiconicLanguages), and to see the modern outgrowth of such things, web search "reflective towers", or see "A Tutorial on Behavioral Reflection and its Implementation" at http://www2.parc.com/csl/groups/sda/projects/reflection96/docs/malenfant/ref96/ref96.html
The usual context is an interpreter for language X implemented using an interpreter for X, but mixed language stuff is widespread too. -- dm
I looked for "substitution" in this page and in SeriousVersusScriptingLanguages and didn't find it in either. Surely this is a key attribute of many languages that we consider ScriptingLanguages. Of the languages of this type I am familiar with, REXX has both symbol substitution and an "interpret" function. I know TCL talks about substitution, rather than setting variables. And of course symbol substitution ties in well with text manipulation, referred to above. -- pm
EditText of this page
(last edited August 21, 2014)
or FindPage with title or text search