Scripting Languages

In the beginning, computers were ferociously expensive devices, to which programs were submitted as sets of punched cards or tapes. This would require having some sort of "control program" to control combining the different components of the process, including such things as:

• Compiling the program,

• Loading the program,

• Indicating the sets of data that the program would access,

• Indicating where output is to go.

In the beginning this generally involved having a few extra punched cards attached to the start of each job in the "hopper." When multitasking systems emerged, more sophisticated "job scheduling" systems emerged. On IBM's systems, this grew into JCL, "Job Control Language." It is worth noting that arguments to the Unix dd(1) command copy from common JCL parameters. More recently, REXX provides a full scale programming language with syntax similar to PL/1 , though JCL is still in widespread use for the purpose.

The Multics innovated the notion of separating the command shell from the operating system kernel, offering the option of having replacement command processors.

On Unix , the Bourne shell has long been used to control basic system functions; the more recent Bash adds in rather more sophisticated data structures.

Between "way back then" and now, developments on such systems as ITS , TOPS-10, and such added sophistication to the "shell languages" with regard to things like job control.

The emergence of Perl added a different kind of sophistication. The original point of Perl was to provide a "reporting language" that would be faster and more maintainable than sets of awk scripts controlled by Bourne shell scripts. From there, things have pretty much just grown: languages like Perl and Python are now full-featured programming languages as opposed to just being the "glue" to connect together programs in "real languages." 

• MS-DOS comes with a shell language called COMMAND.COM. It is a singularly unpowerful command language, commonly replaced using a product called 4DOS.

• Linux is an unusually active platform in the area of scripting.

• Note that many scripting systems are described using the term macros. While the origin of their use of the term may be rational, they typically do not truly involve the use of macros in a true sense.

• On The Overuse of Perl contends that many of the "web things" for which Perl is used might be better replaced by compiled C code.

  The arguments are fairly sound; the Perl "environment" involves a large quantity of basic binaries and shared libraries, on top of which must be loaded any additional Perl code to deal with whatever CPAN modules you then add in.

  For repetitively spawned CGI scripts or small tools which get loaded repetitively from scratch, this argues quite well, and is equally applicable to other scripting languages such as Python or PHP.

  For CGI applications, the importance of this has diminished over time, as it has become common for web servers like Apache to have some "linking scheme" whereby the Perl instance (or whatever other language) gets loaded in some persistent manner so that the same instance may be used serially for multiple scripts, or even with multiple threads executing concurrently.

  Another excellent example is Mozilla, which consists of an HTML rendering engine, with the user interface defined using their XML -based XUL language with script code written mostly in JavaScript . Mozilla is pretty enormous, and loads in a great deal of its executable code at runtime. That script code cannot be shared between multiple Mozilla instances.

  Nonetheless, if you find you have a web application that is overloading the server, this represents a useful perspective from which to analyze possible solutions.

• Scripting Language