Scripting languages are often used for one-off programming jobs and for prototyping. Scripting is also used in some large generic applications as a flexible way to configure generic software components to fit specialist requirements. Today a bewildering variety of scripting languages offer a range of powerful features. This article will illustrate some practical applications of scripting and provide an introduction to some of the most widely used scripting languages.
Scripting languages are programming languages. Although it's difficult to arrive at a definitive definition of "scripting", a scripting language is likely to be untyped (or weakly typed), interpreted and run from plain-text files. Scripting languages often emphasise ease of development over runtime efficiency and ease of deployment. From this point of view it's tempting to think that scripting languages are inferior to ordinary "production" programming languages. Rather than considering them to be inferior, consider that they offer a different set of strengths and weaknesses to conventional programming languages. This is something that becomes apparent by examining the practical uses of scripting.
Scripting languages allow programs to be written more quickly because they're more terse, assume a dynamic, interpreted environment (where parts of the program can change at runtime) and because they often contain powerful built-in operators and data types such as hash tables and expandable lists.
Practical uses of scripting
Systems administration
If you're reading this article on a Windows, Linux or Unix-based system the chances are that one or more scripts played an important part setting your system up for use when the power was turned on. Professional Unix systems administrators and webmasters often write specialised scripts to control internet and intranet servers - automatically performing maintenance tasks such as performing backups, checking for service failures and performing "one-off" data conversion chores. If you're thinking of becoming a systems administrator or a database administrator, you should seriously consider learning at least one of the scripting languages that are used on the platform with which you'll be working.
Automating software development
Software developers often perform the same routine tasks, for example building programs from a set of resource files, launching tests, writing header files, checking a set of changed files back into a source-code control system and building a complete image of a product ready for release. In a development team there are thousands of minute variations in the ways that manual development tasks can be configured. In product development, an inconsistency or even a fault could be introduced by a tiny difference between your development environment and that of another developer. Such problems could occur simply because you didn't realise that the order in which two particular tasks are performed is important. If you and your team perform the same tedious tasks frequently those tasks are candidates for what software consultants Andy Hunt and Dave Thomas call "ubiquitous automation". [1] Learn to use a scripting language to automate those tedious tasks. Apart from reducing the risk of introducing inconsistencies, it's easier to concentrate on development when you're not trying to remember long sequences of commands, or a series of mouse clicks. Scripting can often be incorporated into a build system. The ant build system, for example, allows developers to write customised tasks in a variety of scripting languages. [2] We can afford this level of automation because scripting languages are designed to automate frequently performed tasks rather than to directly support the construction of large, robust, consumer applications. This use of scripting is similar to the construction of moulds, templates and jigs by craftsmen.
"Common-off-the-shelf" package customisation
Although scripting systems have their roots in the old text-based systems of the sixties and seventies, the later half of the nineties saw many modern, graphical systems being retrofitted with powerful script and component-based facilities that allow a considerable amount of automation. Both Apple and Microsoft have continued to integrate new scripting infrastructure into their systems in recent years. On the windows platform, old batch-file scripting has been augmented by a new system called Windows Scripting Host (WSH). Windows scripting host is an environment in which various scripting languages can be installed. [3] (By default, WSH comes installed with VBScript and Jscript, Microsoft's Javascript-like language.) Once installed into the scripting host environment scripts written in these languages can drive various parts of the system and programs that implement "ActiveX automation". I have worked on one project in a Microsoft-based environment where a simple WSH script was used to automate the process of converting documents from an internal format into Microsoft Word format.
Large, generic software packages often cater for several different types of users. Both a technical publisher and a legal practice for example may buy the same word processor. Both the technical author and the legal practice are likely to have specialist tasks that could be automated in the word processor. Rather than try to keep up with an ever increasing list of specialist features, software houses often introduce a programmable "macro" or "scripting" facility into their product so that third party vendors and power-users can customise these general packages for specialist use. In Microsoft Office, for example, there is a built-in scripting environment called Visual Basic for Applications (or VBA). In a similar manner, the StarOffic package from Sun Microsystems can be customised by scripting in the OfficeBasic and Javascript languages.