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 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 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.
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.