Recent from talks
Contribute something
Nothing was collected or created yet.
Scripting language
View on WikipediaThis article includes a list of general references, but it lacks sufficient corresponding inline citations. (August 2024) |

In computing, a script is a relatively short and simple set of instructions that typically automate an otherwise manual process. The act of writing a script is called scripting. A scripting language or script language is a programming language that is used for scripting.[1]
Originally, scripting was limited to automating shells in operating systems, and languages were relatively simple. Today, scripting is more pervasive and some scripting languages include modern features that allow them to be used to develop application software also.
Overview
[edit]A scripting language can be a general-purpose programming language or a domain-specific language for a given environment. When embedded in an application, it may be called an extension language.
A scripting language is sometimes referred to as very high-level programming language if it operates at a high level of abstraction, or as a control language, especially for job control languages on mainframe computers.
The term scripting language is sometimes used in a wider sense, to refer to dynamic high-level programming languages in general. Some are strictly interpreted languages, while others use a form of compilation. In this context, the term script refers to a small program in such a language; typically, contained in a single file, and no larger than a few thousand lines of code.
The scope of scripting languages ranges from small to large, and from highly domain-specific language to general-purpose programming languages. A language may start as small and highly domain-specific and later develop into a portable and general-purpose language; conversely, a general-purpose language may later develop special domain-specific dialects.
Notable languages
[edit]- AWK, for text-processing, generally available in Unix-like operating systems
- Batch file language (BAT), for scripting Microsoft Windows
- Bourne shell, interpreted language for scripting Unix and Unix-like operating systems
- C, via Tiny C Compiler
- Groovy, Java-like, object-oriented scripting
- Java, using JBang[2]
- JavaScript (later: ECMAScript), originally limited to running in a web browser to dynamically modify a web page; later enhanced into a widely portable, general-purpose programming language
- Linden Scripting Language, custom, extension language for scripting Second Life virtual world
- Lisp, family of general-purpose and extension languages for applications including Emacs Lisp for Emacs
- Lua, extension language used by many applications
- Perl,[3] text-processing language that later developed into a general-purpose language; also used as an extension language for various applications
- PowerShell, for scripting Microsoft Windows, macOS and Linux
- Python, general-purpose and extension language
- Rexx, general-purpose language that runs on many platforms; also used as extension language
- Ruby, multiple-paradigm, general-purpose language
- sed, for text-processing; available in most Unix-like operating systems and ported to other operating systems
- Tcl,[4] for Unix-like environments, popular in the 1990s; can be used in conjunction with Tk to develop GUI applications
- TrainzScript, custom, extension language for Trainz railroad simulators
- VBScript, for scripting Microsoft Windows
- Visual Basic for Applications (VBA), an extension language available in Microsoft Office applications
Characteristics
[edit]Script is a subjective characterization that generally includes the following attributes.
Interpreted
[edit]A script is usually not compiled, at least not its usual meaning. Generally, they are interpreted directly from source code, or from bytecode, or run as native after just-in-time compilation.[5]
Short & simple
[edit]A script is generally relatively short and simple. As there is no limit on size or complexity, script is subjective. A few lines of code without branching is probably considered a script. A codebase of multiple files, that performs sophisticated user or hardware interface or complicated algorithms or multiprogramming is probably not considered a script.
Automates
[edit]A script usually automates a task that would otherwise be performed by a person in a more manual way.
Limited language
[edit]A language that is primarily intended for scripting generally has limited capabilities compared to a general-purpose language. A scripting language may lack the functionality to write complex applications.
Starts at the top
[edit]Typically, a script starts executing at the first line of code whereas an application typically starts at a special point in the code called the entry point.
For example, Java is not script-like since an application starts at the function named main which need not be at the top of the code. The following code starts at main, then calls printHelloWorld which prints "Hello World".
public class HelloWorld {
public static void printHelloWorld() {
System.out.println("Hello World");
}
public static void main(String[] args) {
printHelloWorld();
}
}
In contrast, the following Python code prints "Hello World" without the main function or other syntax such as a class definition required by Java.
print("Hello World")
Single user
[edit]Scripts are often created or modified by the person executing them,[6] but they are also often distributed, such as when large portions of games are written in a scripting language, notably the Google Chrome T-rex game.
History
[edit]Early mainframe computers (in the 1950s) were non-interactive, instead using batch processing. IBM's Job Control Language (JCL) is the archetype of languages used to control batch processing.[7]
The first interactive shells were developed in the 1960s to enable remote operation of the first time-sharing systems, and these used shell scripts, which controlled running computer programs within a computer program, the shell. Calvin Mooers in his TRAC language is generally credited with inventing command substitution, the ability to embed commands in scripts that, when interpreted, insert a character string into the script.[8] Multics calls these active functions.[9] Louis Pouzin wrote an early processor for command scripts called RUNCOM for CTSS around 1964. Stuart Madnick at MIT wrote a scripting language for IBM's CP/CMS in 1966. He originally called this processor COMMAND, later named EXEC.[10] Multics included an offshoot of CTSS RUNCOM, also called RUNCOM.[11] EXEC was eventually replaced by EXEC 2 and Rexx.
Languages such as Tcl and Lua were specifically designed as general-purpose scripting languages that could be embedded in any application. Other languages such as Visual Basic for Applications (VBA) provided strong integration with the automation facilities of an underlying system. Embedding of such general-purpose scripting languages instead of developing a new language for each application also had obvious benefits, relieving the application developer of the need to code a language translator from scratch and allowing the user to apply skills learned elsewhere.
Some software incorporates several different scripting languages. Modern web browsers typically provide a language for writing extensions to the browser itself, and several standard embedded languages for controlling the browser, including JavaScript (a dialect of ECMAScript) or XUL.
Types
[edit]Scripting languages can be categorized into several different types, with a considerable degree of overlap among the types.
Glue languages
[edit]Scripting is often contrasted with system programming, as in Ousterhout's dichotomy or "programming in the large and programming in the small". In this view, scripting is glue code, connecting software components, and a language specialized for this purpose is a glue language. Pipelines and shell scripting are archetypal examples of glue languages, and Perl was initially developed to fill this same role. Web development can be considered a use of glue languages, interfacing between a database and web server. But if a substantial amount of logic is written in script, it is better characterized as simply another software component, not "glue".
Glue languages are especially useful for writing and maintaining:
- custom commands for a command shell;[12]
- smaller programs than those that are better implemented in a compiled language;[13]
- "wrapper" programs for executables, like a batch file that moves or manipulates files and does other things with the operating system before or after running an application like a word processor, spreadsheet, data base, assembler, compiler, etc.;[14]
- scripts that may change;[15]
- Rapid application development of a solution eventually implemented in another, usually compiled, language.[citation needed]
Glue language examples:
- AppleScript
- CoffeeScript
- ColdFusion
- DCL
- ECL
- Embeddable Common Lisp
- Erlang
- EXEC, EXEC2
- JavaScript, JScript
- Job Control Language (JCL)
- Julia
- Lua
- m4
- Perl (5 and Raku)
- PHP
- PowerShell
- Pure
- Python
- Rebol
- Red
- Rexx
- NetRexx
- Ruby
- Scheme
- Tcl
- Unix shell scripts (ksh, csh, bash, sh and others)
- VBScript
- Work Flow Language
- XSLT
Macro languages exposed to operating system or application components can serve as glue languages. These include Visual Basic for Applications, WordBasic, LotusScript, CorelScript, Hummingbird Basic, QuickScript, Rexx, SaxBasic, and WinWrap Basic. Other tools like AWK can also be considered glue languages, as can any language implemented by a Windows Script Host engine (VBScript, JScript and VBA by default in Windows and third-party engines including implementations of Rexx, Perl, Tcl, Python, XSLT, Ruby, Modern Pascal, Delphi, and C). A majority of applications can access and use operating system components via the object models or its own functions.
Other devices like programmable calculators may also have glue languages; the operating systems of PDAs such as Windows CE may have available native or third-party macro tools that glue applications together, in addition to implementations of common glue languages—including Windows NT, DOS, and some Unix shells, Rexx, Modern Pascal, PHP, and Perl. Depending upon the OS version, WSH and the default script engines (VBScript and JScript) are available.
Programmable calculators can be programmed in glue languages in three ways. For example, the Texas Instruments TI-92, by factory default can be programmed with a command script language. Inclusion of the scripting and glue language Lua in the TI-NSpire series of calculators could be seen as a successor to this. The primary on-board high-level programming languages of most graphing calculators (most often Basic variants, sometimes Lisp derivatives, and more uncommonly, C derivatives) in many cases can glue together calculator functions—such as graphs, lists, matrices, etc. Third-party implementations of more comprehensive Basic version that may be closer to variants listed as glue languages in this article are available—and attempts to implement Perl, Rexx, or various operating system shells on the TI and HP graphing calculators are also mentioned. PC-based C cross-compilers for some of the TI and HP machines used with tools that convert between C and Perl, Rexx, AWK, and shell scripts to Perl, Modern Pascal, VBScript to and from Perl make it possible to write a program in a glue language for eventual implementation (as a compiled program) on the calculator.[citation needed]
Editor languages
[edit]A number of text editors support macros written either using a macro language built into the editor, e.g., The SemWare Editor (TSE), vi improved (VIM), or using an external implementation, e.g., XEDIT, or both, e.g., KEDIT. Sometimes text editors and edit macros are used under the covers to provide other applications, e.g., FILELIST and RDRLIST in CMS .
Job control languages and shells
[edit]A major class of scripting languages has grown out of the automation of job control, which relates to starting and controlling the behavior of system programs[16] (in this sense, one might think of shells as being descendants of IBM's JCL, or Job Control Language, which was used for exactly this purpose). Many of these languages' interpreters double as command-line interpreters such as the Unix shell or the MS-DOS COMMAND.COM. Others, such as AppleScript offer the use of English-like commands to build scripts.
GUI scripting
[edit]With the advent of graphical user interfaces, a specialized kind of scripting language emerged for controlling a computer. These languages interact with the same graphic windows, menus, buttons, and so on, that a human user would. They do this by simulating the actions of a user. These languages are typically used to automate user actions. Such languages are also called macros when control is through simulated key presses or mouse clicks, and tapping or pressing on a touch-activated screen.
These languages could in principle be used to control any GUI application; but, in practice their use is limited because their use needs support from the application and from the operating system. There are a few exceptions to this limit. Some GUI scripting languages are based on recognizing graphical objects from their display screen pixels. These GUI scripting languages do not depend on support from the operating system or application.
When the GUI provides the appropriate interfaces, as in the IBM Workplace Shell, a generic scripting language, e.g., Object REXX, can be used to write GUI scripts.
Application-specific languages
[edit]Application specific languages can be split in many different categories, i.e., standalone based app languages (executable) or internal application specific languages (PostScript, XML, gscript as some of the widely distributed scripts, respectively implemented by Adobe, Microsoft and Google) among others include an idiomatic scripting language tailored to the needs of the application user. Likewise, many computer game systems use a custom scripting language to express the programmed actions of non-player characters and the game environment. Languages of this sort are designed for a single application; and, while they may superficially resemble a specific general-purpose language (e.g., QuakeC, modeled after C), they have custom features that distinguish them. Emacs Lisp, while a fully formed and capable dialect of Lisp, contains many special features that make it most useful for extending the editing functions of Emacs. An application-specific scripting language can be viewed as a domain-specific programming language specialized to one application.
Extension/embeddable languages
[edit]A number of languages have been designed for the purpose of replacing application-specific scripting languages by being embeddable in application programs. The application programmer (working in C or another systems language) includes "hooks" where the scripting language can control the application. These languages may be technically equivalent to an application-specific extension language but when an application embeds a "common" language, the user gets the advantage of being able to transfer skills from application to application. A more generic alternative is simply to provide a library (often a C library) that a general-purpose language can use to control the application, without modifying the language for the specific domain.
JavaScript began as, and still is mostly, a language for scripting inside web browsers. However, the standardizing of the language as ECMAScript has made it popular as a general-purpose embeddable language. The Mozilla implementation SpiderMonkey is embedded in several environments such as the Yahoo Widgets Engine,and applications such as the Adobe products Flash (ActionScript) and Acrobat (for scripting PDF files).
Tcl was created as an extension language but has come to be used more often as a general-purpose language in roles similar to Python, Perl, and Ruby. In contrast, Rexx was created as a job control language, but is widely used as an extension language and a general-purpose language. Perl is a general-purpose language, but had the Oraperl (1990) dialect, consisting of a Perl 4 binary with Oracle Call Interface compiled in. This has however since been replaced by a library (Perl Module), DBD::Oracle.[17][18]
Other complex and task-oriented applications may incorporate and expose an embedded programming language to allow their users more control and give them more functionality than can be available through a user interface, no matter how sophisticated. For example, Autodesk Maya 3D authoring tools embed the Maya Embedded Language, or Blender which uses Python to fill this role.
Some other types of applications that need faster feature addition or tweak-and-run cycles (e.g. game engines) also use an embedded language. During the development, this allows them to prototype features faster and tweak more freely, without the need for the user to have intimate knowledge of the inner workings of the application or to rebuild it after each tweak (which can take a significant amount of time). The scripting languages used for this purpose range from the more common and more famous Lua and Python to lesser-known ones such as AngelScript and Squirrel.
See also
[edit]References
[edit]- ^ "ECMAScript 2019 Language Specification". Ecma International. Retrieved 2018-04-02.
- ^ "JBang". jbang.dev. Retrieved 11 September 2025.
- ^ Sheppard, Doug (2000-10-16). "Beginner's Introduction to Perl". Perl.com. Retrieved 2011-01-08.
- ^ Wall, Larry (2007-12-12). "Programming is Hard, Let's Go Scripting". Perl.com. Archived from the original on December 8, 2023.
- ^ Brown, Vicki; Morin, Rich (1999). "Scripting Languages". MacTech. Retrieved 2009-07-22.
- ^ Loui, Ronald. "In Praise of Scripting: Real Programming Pragmatism". IEEE Computer. Archived from the original on 2015-09-23. Retrieved 2013-08-27.
- ^ IBM Corporation (March 1967). IBM System/360 Operating System Job Control Language (C28-6529-4) (PDF). Archived (PDF) from the original on May 25, 2023 – via bitsavers.
- ^ Mooers, Calvin (1965). "TRAC, A Procedure-Describing Language for the Reactive Typewriter". TRAC Foundation. Archived from the original on 2001-04-25. Retrieved March 9, 2012.
- ^ Van Vleck, Thomas (ed.). "Multics Glossary – A — (active function)". Multics. Retrieved March 9, 2012.
- ^ Varian, Melinda (April 1991). "VM and the VM Community: Past, Present, and Future" (PDF). Archived from the original (PDF) on October 6, 2011. Retrieved March 9, 2012.
- ^ Van Vleck, Thomas (ed.). "Multics Glossary – R — (RUNCOM)". Retrieved March 9, 2012.
- ^ "What is glue code (glue code language)? - Definition from WhatIs.com". WhatIs.com. Retrieved 2022-01-31.
- ^ Larson, Quincy (10 January 2020). "Interpreted vs Compiled Programming Languages". Free Code Camp. Retrieved 23 February 2022.
- ^ Balkis, Anton. "Script Adalah". Raja Tips. Retrieved 23 February 2022.
- ^ Axelsson, Mats. "Shell scripts - What can you change". Linux Hint. Retrieved 23 February 2022.
- ^ "Job Control Basics (Bash Reference Manual)". GNU. Retrieved 2022-05-20.
- ^ "Oraperl - [Deprecated Perl access to Oracle databases for old oraperl scripts]", metacpan.
- ^ "Perl", Underground Oracle FAQ.
- ^ van Rossum, Guido (January 6–8, 1998). "Glue It All Together With Python". Python.org. Archived from the original on January 19, 2024.
Further reading
[edit]- Barron, David William (2001). The World of Scripting Languages. Wiley. ISBN 0-471-99886-9.
External links
[edit]- Patterns for Scripted Applications at the Wayback Machine (archived October 10, 2004)
Scripting language
View on GrokipediaDefinition and Overview
Core Concepts
A scripting language is a programming language designed primarily for integrating and communicating with existing applications or environments, enabling the coordination of complex components without the need for low-level system programming.[1] These languages facilitate tasks such as connecting disparate software modules or automating interactions within a runtime context, where code is executed directly rather than compiled into machine code beforehand.[1] This design prioritizes ease of use in dynamic settings, allowing developers to prototype and deploy solutions rapidly by leveraging pre-existing tools and libraries.[5] Scripting languages emphasize non-compiled execution, typically through interpretation at runtime, which supports quick iteration and modification without lengthy build processes.[1] For instance, in runtime environments like command-line shells or web browsers, scripts can be run on-the-fly to perform immediate tasks, reducing development cycles from hours to minutes.[6] This interpreted nature contrasts with compiled languages and enables seamless embedding within host applications for real-time control.[1] The term "scripting language" was coined in the late 1980s by John Ousterhout, creator of Tcl, to distinguish these languages from traditional system programming languages like C, which focus on performance and low-level control.[1] Ousterhout highlighted their role in providing a higher-level abstraction for application integration, as detailed in his influential 1998 paper.[1] At their core, scripting languages serve purposes such as automating sequences of commands to streamline repetitive operations, gluing together heterogeneous components into cohesive workflows, and extending the functionality of host software through embeddable scripts.[1] These capabilities make them ideal for tasks requiring flexibility, such as system administration via languages like Bash or client-side web interactions with JavaScript.Distinctions from Other Languages
Scripting languages differ from compiled languages, such as C++, primarily in their execution model and design priorities. Unlike compiled languages that undergo ahead-of-time compilation to machine code for optimal performance, scripting languages are generally interpreted at runtime, allowing for immediate execution without a separate compilation step.[7] This approach enables rapid prototyping and development but trades off execution efficiency, as interpreters introduce overhead compared to native code.[8] For instance, Ousterhout notes that scripting languages "give up execution speed... relative to system programming languages in order to achieve rapid development and higher-level abstractions," with productivity gains often estimated at 5-10 times higher than in compiled environments.[8] In contrast to general-purpose languages like Java, which compile to bytecode and enforce static typing with strict syntax checks at compile time, scripting languages typically feature dynamic typing—where variable types are determined during execution—and more flexible, concise syntax to facilitate quick scripting tasks.[9] This looseness reduces boilerplate code and error-prone declarations, making scripting languages suitable for automation and integration, though it can lead to runtime errors not caught early.[7] Additionally, many scripting languages are designed to operate within specific hosts or interpreters, such as JavaScript in web browsers, limiting their standalone nature compared to the broader applicability of general-purpose languages.[9] Scripting languages do not form a strict category but exist on a spectrum, where some, like Python, blur distinctions by functioning effectively as both lightweight scripting tools and full-fledged general-purpose languages for large-scale applications.[9] This overlap highlights evolving usage patterns, with metrics like development speed (favoring scripting for quick iterations) versus execution efficiency (favoring compiled languages for performance-critical systems) serving as key differentiators.[8] Portability also varies, as scripting languages depend on the availability of their interpreters across environments, offering broad cross-platform compatibility without recompilation, unlike some compiled languages tied to specific architectures.[9]Key Characteristics
Interpreted and Dynamic Nature
Scripting languages are typically executed through an interpreter that reads and processes the source code line-by-line at runtime, without the need for prior compilation into binary machine code. This approach enables rapid iteration and development cycles, as programmers can test and modify code immediately without undergoing a separate compilation step. A key feature of scripting languages is their dynamic typing and binding, where the types of variables and the bindings of functions are determined and resolved during execution rather than at compile time. This runtime resolution supports late binding and polymorphism, permitting flexible code that adapts to different data types without requiring explicit static type declarations or checks.[10] The interpreted and dynamic nature of scripting languages offers several advantages, including reduced boilerplate code due to the absence of type annotations and easier debugging through interactive execution environments that allow immediate feedback on changes. However, these benefits come with trade-offs: runtime type resolution can lead to errors that only surface during execution, potentially complicating maintenance, and the lack of static optimizations often results in slower performance compared to compiled languages.[11][12] The execution model of scripting languages has evolved significantly, tracing back to early interpreters in Lisp variants that emphasized dynamic features for symbolic computation and rapid prototyping in the 1950s and 1960s. Modern implementations have advanced beyond pure interpretation by incorporating just-in-time (JIT) compilation, as seen in the V8 engine for JavaScript, which introduced an optimizing JIT compiler in 2010 to generate machine code dynamically and substantially improve runtime performance while retaining the flexibility of dynamic typing.[13][14]Simplicity and Conciseness
Scripting languages emphasize syntactic simplicity to facilitate rapid development and readability for short scripts, often employing minimal keywords and flexible syntax structures. For instance, Perl supports "one-liners," concise command-line expressions that perform complex tasks like text processing in a single line, leveraging operators and built-in functions without verbose declarations.[15] Similarly, Python uses indentation-based blocks to delineate code structure, eliminating the need for delimiters like braces or keywords such as "end," which enhances visual clarity and reduces boilerplate.[16] This approach aligns with the design goal of enabling developers to focus on logic rather than syntax overhead. Conciseness in scripting languages manifests in higher code density for routine operations, allowing fewer lines to achieve functionality compared to more verbose general-purpose languages. A comparative analysis of solutions from the Rosetta Code repository across eight languages found that scripting languages like Python and Ruby required significantly shorter code for tasks involving string manipulation and data processing than object-oriented languages such as Java, where explicit class definitions and type declarations inflate script length.[17] This brevity stems from dynamic typing and operator overloading, which streamline expressions without sacrificing expressiveness for common scripting scenarios. Scripting languages incorporate built-in high-level abstractions through standard libraries that handle operations like file I/O, networking, and regular expressions, abstracting away low-level details such as memory management or socket initialization. In Python, the built-inopen() function and io module provide straightforward file handling, while the re module enables pattern matching without external dependencies; similarly, modules like urllib offer high-level HTTP interactions. These features promote productivity by allowing scripts to interface directly with system resources, as seen in Perl's core functions for file operations and regex integration.
However, extreme conciseness can lead to trade-offs, such as producing "write-only" code that is difficult for others to comprehend or maintain due to dense, symbolic expressions. This critique is notably applied to APL, where array-oriented notation enables compact solutions but often results in opaque code requiring specialized knowledge to interpret, limiting collaborative reuse.[18]
Automation and Task-Oriented Design
Scripting languages are engineered primarily to automate workflows by orchestrating sequences of commands, processes, and data flows, enabling the execution of repetitive or complex operations without the overhead of developing complete standalone applications. This design allows developers and administrators to connect disparate tools and systems efficiently, focusing on task logic rather than low-level implementation. As articulated by John K. Ousterhout, scripting represents a paradigm for higher-level programming that emphasizes productivity in "gluing" applications together and automating routine activities, distinct from the detailed control required in system programming languages like C.[1] Central to their task-oriented nature are features such as scripting engines that facilitate batch processing, where multiple commands are executed sequentially or in groups to handle bulk operations like data transformation or system maintenance. Event-driven execution further enhances automation by allowing scripts to respond dynamically to triggers, such as file changes or user interactions, as seen in JavaScript's handling of browser events for interactive web tasks. Additionally, seamless integration with APIs enables scripting languages to fetch, process, and send data across services; for instance, Python's standard library supports HTTP requests for API interactions in automation pipelines.[19][20][21] Task orientation manifests in core primitives tailored for common automation needs, including string manipulation for text processing, file handling for data management, and process spawning for executing external programs. Perl, renowned for its robust regular expression support, provides efficient operators like substitution and matching to manipulate strings in log analysis or data extraction scripts. Python offers straightforward file I/O functions, such asopen() and with statements, to read, write, and organize files in automated backups or report generation. In Bash, commands like & and exec enable process spawning, allowing scripts to launch and monitor subprocesses for tasks like parallel job execution.[22][23][24]
Philosophically, scripting embodies a higher-level abstraction over system calls, encapsulating low-level operations into intuitive constructs that minimize boilerplate code and reduce cognitive load on developers. By providing built-in facilities for these primitives, scripting languages shift emphasis from hardware intricacies to problem-solving, enabling rapid prototyping and maintenance of automation solutions. This abstraction aligns with Ousterhout's vision of scripting as a means to achieve software productivity comparable to natural language expressiveness.[1]
Scope Limitations and Embeddability
Scripting languages are typically constrained in scope to high-level operations, such as automation, configuration, and rapid prototyping, without providing direct access to hardware resources like memory allocation or device drivers.[25] This design choice prioritizes ease of use and safety over low-level control, making them unsuitable for performance-critical applications requiring fine-grained optimization or real-time hardware interaction. As a result, they often defer such tasks to the underlying host system or compiled languages, focusing instead on concise expression for domain-specific tasks.[26] A core aspect of many scripting languages is their embeddability, allowing them to be integrated as extensions within larger applications written in systems languages like C or C++.[27] For instance, Lua is designed with a minimal C API that facilitates seamless hosting in host environments, enabling customization in resource-constrained settings such as games.[28] Similarly, JavaScript is embedded within web browsers via dedicated engines, permitting dynamic client-side scripting without standalone execution. This embeddability stems from their lightweight interpreters and portable implementations, which avoid complex bootstrapping mechanisms.[29] In terms of programming paradigms, scripting languages provide sufficient expressiveness for extension mechanisms—such as event handling or configuration logic—but eschew low-level primitives like manual memory management or pointer arithmetic to maintain simplicity and prevent errors in hosted contexts.[30] Lua, for example, relies on automatic garbage collection and dynamic typing to support procedural and data-driven styles without exposing users to systems-level details.[28] This approach ensures they serve as "glue" for integrating components rather than building full-scale systems.[27] The benefits of these scope limitations and embeddability include safer integration, as the host environment enforces security boundaries and handles resource-intensive operations, reducing the risk of crashes or exploits.[29] Additionally, their small footprint—such as Lua's core library under 500 KB—allows efficient deployment in embedded systems without bloating the host application.[28] However, drawbacks arise from dependency on the host for essential functions like input/output and data persistence, which can introduce performance overhead or restrict portability if the host lacks adequate bindings.[31] This reliance may also complicate debugging, as errors in the script can propagate unpredictably through the host interface.[27]Historical Development
Early Origins (1950s–1970s)
The origins of scripting languages trace back to the batch processing era of mainframe computing in the 1950s, where early systems relied on punched-card decks to sequence and control jobs without interactive user input. These setups, common on machines like the IBM 701, treated programs as non-interactive batches submitted via physical media, with rudimentary control mechanisms to prioritize and execute tasks in sequence. This approach laid the groundwork for automating repetitive operations in resource-constrained environments.[32] By the mid-1960s, more structured job control emerged with IBM's Job Control Language (JCL), introduced alongside the OS/360 operating system in 1964, which allowed users to script batch job submissions, resource allocation, and program execution on mainframes. JCL's declarative syntax enabled operators to define job steps, datasets, and conditions, marking a shift toward programmatic control of system workflows. Concurrently, precursors to modern shells appeared, such as Louis Pouzin's RUNCOM facility developed in 1964 for the Compatible Time-Sharing System (CTSS), which permitted users to store and execute sequences of commands from files, introducing basic scripting for command automation. Pouzin later coined the term "shell" while adapting these ideas for the Multics operating system.[33][34] In 1958, John McCarthy developed Lisp (LISt Processor) at MIT, one of the first interpreted programming languages, designed for symbolic manipulation and list processing with dynamic evaluation of expressions. Although primarily for artificial intelligence research, Lisp's interpreter and flexibility in handling symbolic data structures influenced later paradigms in interpreted and dynamic languages, including aspects of scripting.[35] The 1970s saw further advancements in interactive scripting with Ken Thompson's shell for the first version of Unix, released in 1971 on the PDP-11 at Bell Labs, which supported simple command sequencing and piping for task automation. This shell provided an interactive interface for executing and chaining system commands, building on Multics influences to streamline user-system interactions. A key milestone in network scripting occurred with the ARPANET, where early languages like the Network Interchange Language (NIL) and Decode-Encode Language (DEL), developed in the early 1970s, enabled automated data exchange and protocol handling across distributed nodes, facilitating rudimentary network automation.[36][37]Expansion in the Personal Computing Era (1980s–1990s)
The advent of personal computing in the 1980s spurred the development of scripting languages tailored to user-level automation and customization on desktop systems. Emacs Lisp emerged as a key extension language for the Emacs text editor, with early implementations like Unix Emacs, developed by James Gosling in 1980–1981, leveraging a Lisp dialect for customizable editor features and macros.[38] This allowed users to extend the editor's functionality through scripts, influencing subsequent editor ecosystems. Similarly, AppleScript was conceived in 1989 by Apple's Advanced Technology Group to enable end-users to automate complex tasks and customize Mac OS applications, providing a natural-language-like syntax for inter-application scripting.[39] Meanwhile, Tcl was created in spring 1988 by John Ousterhout at the University of California, Berkeley, initially as an embeddable command language for integrating tools in integrated circuit design, but quickly adapted for graphical user interface (GUI) scripting with the companion Tk toolkit.[40] Perl, developed by Larry Wall in December 1987 as a Unix scripting language, combined features from awk, sed, and C to simplify text processing and report generation, addressing limitations in existing tools for handling unstructured data. Its popularity surged in the 1990s due to robust regular expression support and cross-platform portability, making it a staple for system administration, web CGI scripting, and data manipulation tasks. Complementing this, the Bourne-Again SHell (Bash), authored by Brian Fox in 1989 for the GNU Project, became the de facto standard Unix shell, enhancing job control features like background processes and signal handling to streamline command-line automation. These developments democratized scripting by embedding it within accessible personal computing environments, often serving as glue languages to integrate disparate tools. The mid-1990s marked scripting's expansion into the emerging web, with JavaScript introduced by Brendan Eich at Netscape in May 1995 as a lightweight, client-side language for adding interactivity to web pages within browsers. Initially named Mocha and later LiveScript, it enabled dynamic content manipulation without server round-trips, fundamentally shaping web development by allowing scripts to respond to user events in real time. This era's scripting innovations, from editor extensions to GUI and web automation, underscored their role in empowering non-programmers with concise, task-oriented code to enhance personal productivity.Modern Proliferation and Influences (2000s–Present)
In the 2000s, scripting languages experienced significant growth driven by the expansion of the web and data processing needs. Python, originally released in 1991, saw a surge in adoption during this decade, particularly for web development and data analysis tasks. The release of Python 2.0 in 2000 introduced features like list comprehensions and garbage collection improvements that enhanced its appeal for rapid prototyping and automation.[41] Frameworks such as Django, launched in 2005, enabled efficient server-side web scripting, powering sites like Instagram and contributing to Python's rise as a versatile tool for dynamic content generation.[42] Concurrently, libraries like NumPy (2006) and scikit-learn (initiated in 2007) solidified Python's role in data scripting, allowing scientists and engineers to handle numerical computations and early machine learning workflows with concise syntax.[43] PHP, introduced in 1995, became a dominant force in server-side scripting throughout the 2000s, underpinning a large portion of dynamic websites. The release of PHP 4.0 in 2000, powered by the Zend Engine, improved performance and added features like session handling, making it accessible for embedding scripts in HTML for tasks such as form processing and database interactions.[44] By the mid-2000s, PHP 5 (2004) introduced object-oriented programming support, further boosting its use in content management systems like WordPress, which by 2005 had begun to power millions of sites.[44] This era marked PHP's proliferation as an open-source staple for cost-effective web backend automation. The 2010s and 2020s witnessed the maturation of JavaScript ecosystems, transforming it from a client-side language into a full-stack scripting powerhouse. Node.js, released in 2009 by Ryan Dahl, enabled server-side JavaScript execution using the V8 engine, allowing non-blocking I/O for scalable web applications and APIs. Its adoption accelerated in the 2010s, with npm package manager facilitating vast ecosystems for tools like Express.js, leading to widespread use in real-time applications such as Netflix's streaming services by 2013.[45] Python's integration with machine learning and AI scripting deepened in this period, exemplified by the launch of Jupyter Notebooks in 2011 as an evolution of IPython. This interactive environment facilitated exploratory data analysis and model prototyping, becoming essential for AI workflows with libraries like TensorFlow (2015) and PyTorch (2016).[46] By the 2020s, Python had become the dominant language for AI scripting among data scientists, driven by its readability and ecosystem maturity. Scripting languages profoundly influenced DevOps and cloud computing paradigms during these decades. Ansible, introduced in 2012 by Michael DeHaan, emerged as a key agentless automation tool using YAML-based playbooks for configuration management and orchestration, simplifying infrastructure scripting across heterogeneous environments. Its adoption in DevOps pipelines grew rapidly, with integrations in tools like Jenkins enabling idempotent deployments for thousands of servers. In cloud scripting, AWS Lambda, previewed in 2014 and generally available in 2015, introduced serverless functions that execute scripts in response to events, eliminating server management for tasks like API backends and data processing. By the 2020s, Lambda supported multiple languages including Python and Node.js, handling billions of invocations daily and reducing operational overhead in microservices architectures.[47] As of 2025, emerging trends highlight scripting's evolution toward enhanced security and automation intelligence. WebAssembly (Wasm), standardized in 2017, has gained traction for secure scripting by providing a sandboxed, memory-safe execution environment that compiles languages like Rust or C++ to browser-compatible binaries, mitigating vulnerabilities in plugin-based extensions.[48] In 2025, Wasm 3.0 added support for garbage collection, improving high-level language support for performant, secure web plugins.[49] Complementing this, AI tools like GitHub Copilot, launched in 2021, have revolutionized script generation by leveraging large language models to autocomplete and suggest code snippets in real-time, accelerating prototyping in languages like Python and JavaScript. As of mid-2025, Copilot has surpassed 20 million users, fostering AI-assisted scripting for rapid iteration in DevOps and data tasks while raising discussions on code ownership and verification.[50]Classification and Types
Glue and Integration Languages
Glue and integration languages, often referred to as glue languages, are a category of scripting languages specifically designed to connect and integrate disparate software components, systems, or tools by acting as intermediaries between different programming environments or applications. These languages enable the orchestration of modules written in various other languages, allowing them to collaborate seamlessly in larger systems without requiring extensive rewriting of existing code.[51] Their primary purpose is to bridge APIs, protocols, and heterogeneous tools, facilitating communication and data flow across boundaries that might otherwise be incompatible.[1] Key characteristics of glue and integration languages include support for cross-language interoperability, typically achieved through mechanisms like foreign function interfaces (FFIs), which permit direct calls to functions in compiled languages such as C or C++, or via automated wrapper generators that create bindings for easier access. They often feature dynamic typing, interpreted execution, and high-level abstractions to simplify integration tasks, prioritizing rapid development over performance-critical computation. For instance, tools like SWIG generate interface code that allows scripting languages to invoke C/C++ functions as if they were native, enhancing modularity in mixed-language projects.[52] This contrasts with system programming languages, which focus on building components from the ground up, whereas glue languages excel at combining pre-existing ones.[1] Historically, glue languages gained prominence in the late 1980s and early 1990s as computing environments grew more modular. A notable early example is Expect, developed by Don Libes and released in 1990 as an extension to the Tcl scripting language, which automated interactions with interactive processes by scripting sequences of expected outputs and responses, effectively gluing human-like terminal sessions to programmatic control for tasks like network automation.[40] Perl emerged as another pioneer in this domain during the same era, leveraging its text-processing strengths to integrate Unix utilities and APIs in practical workflows. In more recent developments, Python has become a de facto standard for glue scripting, with built-in modules like subprocess enabling the invocation and coordination of external programs and processes, thus bridging scripting with system-level tools.[53] Common use cases for these languages include constructing extract, transform, and load (ETL) pipelines, where they integrate data from diverse sources—such as databases, files, or web services—apply transformations, and route results to storage systems; Python-based scripts in AWS Glue exemplify this by processing large-scale data flows using Apache Spark under the hood.[54] Another critical application is middleware scripting, where glue languages connect enterprise software components across protocols like HTTP or message queues, enabling real-time data exchange in distributed architectures without deep modifications to core systems. While there is some overlap with embeddable scripting languages that integrate directly into host applications, glue languages emphasize loose coupling across independent, often externally developed, components.[53]Shell and Job Control Languages
Shell and job control languages are scripting languages designed primarily for interacting with operating system environments, particularly Unix-like systems, to manage processes, execute commands, and control jobs such as background tasks and input/output redirection. These languages serve as command-line interpreters that enable users to automate system-level operations through scripts, focusing on orchestrating external programs rather than performing intensive computations internally.[3] Core features of these languages include command invocation, which allows the execution of external binaries or built-in commands via simple syntax likecommand [arguments], facilitating direct interaction with the OS kernel for process creation. Piping, introduced in early Unix shells, enables the chaining of command outputs to inputs using the | operator, allowing data streams to flow between processes for tasks like filtering or transformation, as seen in pipelines such as ls | [grep](/page/Grep) .txt. Environment variables provide dynamic configuration, with mechanisms to set, read, and export them; for instance, Bash handles the $PATH variable to search directories for executable files during command resolution, ensuring portability across sessions.[55]
The evolution of shell languages began with Ken Thompson's Thompson shell in the Version 6 Unix release of 1971, which provided basic command execution and I/O redirection but lacked advanced scripting constructs. This was superseded by the Bourne shell in 1977, developed by Stephen Bourne for Version 7 Unix, introducing control structures like if-then-else, loops, and functions that made scripted job control more practical for automation. Subsequent developments included the C shell (csh) in 1978 by Bill Joy, adding history substitution and job control features like fg and bg for managing foreground and background processes. By the 1980s, the Korn shell (ksh) in 1983 enhanced these with better scripting capabilities, influencing modern variants. The Z shell (zsh), released in 1990 by Paul Falstad, built on these foundations with advanced scripting features such as improved autocompletion, themeable prompts, and extensible syntax, while maintaining compatibility with POSIX standards.[3][3][3]
Standardization efforts culminated in the POSIX specifications, with IEEE Std 1003.1-1988 defining core system interfaces and IEEE Std 1003.2-1992 specifying the shell command language and utilities, ensuring portability of scripts across compliant systems by mandating features like variable expansion, redirection operators (> and <), and job control signals. These standards, developed by the IEEE POSIX working group, addressed variations in early shells to promote interoperability in Unix environments.[56]
Despite their strengths in system management, shell languages have limitations for complex logic, as they lack robust data structures like arrays or objects beyond basic lists, leading to error-prone handling of strings and word splitting that can introduce security issues like command injection. They excel in linear, sequential tasks such as file manipulation or process orchestration but become unwieldy for algorithmic computations or modular programming, where higher-level languages are preferred.[57][57]
Extension and Embeddable Languages
Extension and embeddable languages are scripting languages specifically engineered to integrate seamlessly into larger host applications, enabling extensibility without requiring recompilation of the core program. These languages provide mechanisms for host applications, typically written in systems languages like C or C++, to execute scripts that customize behavior, automate tasks, or add features at runtime. By design, they emphasize simplicity in integration, allowing developers to extend applications dynamically while maintaining control over the scripting environment.[58] A primary embedding mechanism in these languages involves C APIs that facilitate communication between the host and the scripting engine. For instance, Lua employs a stack-based API where the host program pushes and pops values onto a virtual stack to pass data to and from Lua scripts, enabling efficient interaction without direct memory access. This approach, part of Lua's C API, includes functions for loading scripts, calling Lua functions, and manipulating global variables, all while keeping the interface minimal and portable across platforms. Similarly, other embeddable languages like Squirrel expose their functionality through C headers, providing routines to compile bytecode, invoke scripts, and bind host functions as native extensions. These APIs ensure that the scripting engine acts as a library linked into the host, supporting both static and dynamic integration.[59][58] Security is a critical concern in embeddable languages, as scripts may originate from untrusted sources and could potentially compromise the host application. To mitigate this, many implement sandboxes that restrict script access to sensitive resources, such as file systems, networks, or system calls, by controlling the global environment and disabling dangerous built-in functions. In Lua, for example, sandboxing is achieved by creating a restricted environment that excludes modules likeos and io, preventing arbitrary code execution while allowing safe computation. This restricted access helps isolate scripts, ensuring they cannot escalate privileges or access host memory directly, thus preserving the integrity of the embedding application.[60]
Prominent examples include Guile, a Scheme implementation developed by the GNU Project as an embeddable extension library, with its origins tracing back to the early 1990s through precursors like GEL aimed at creating a universal extension runtime. Guile's design allows C programs to initialize the interpreter, evaluate Scheme code, and expose host procedures, making it suitable for applications requiring flexible scripting. Another example is Squirrel, a lightweight language tailored for real-time applications like games, where it embeds via a simple C API to script behaviors in engines such as those used in Valve's Source platform. Squirrel's focus on object-oriented scripting with reference counting supports efficient integration in performance-sensitive environments.[61][62][63]
Core design principles of these languages prioritize a lightweight runtime to minimize overhead in resource-constrained hosts, often achieving small memory footprints—Lua's core, for instance, fits in under 200 KB—and fast startup times. They also emphasize minimal dependencies, implementing the entire engine in standard ANSI C without reliance on external libraries, which enhances portability and reduces integration complexity. This approach ensures that embeddable languages serve as efficient "glue" for extending applications while adhering to the scope limitations of their host environments.[60][63]
