Scripts

In short: Short, usually interpreted (not compiled) programs that automate a specific task — e.g. a build script, a deployment script, or a one-off data migration script.

In more detail: Scripting languages (Bash, Python, JavaScript via Node.js) are typically not precompiled like C/Java, but interpreted directly at runtime — practical for smaller, frequently changed automation tasks rather than full, performance-critical applications.

In Depth

Interpreted instead of compiled

#!/bin/bash
for file in *.txt; do
  echo "Processing $file"
  mv "$file" "archive/$file"
done

Scripting languages (Bash, Python, JavaScript via Node.js) are typically not precompiled into machine code like C/Java, but read and executed directly at runtime by an interpreter. The appeal lies in the low barrier to entry: no separate compilation needed, immediately executable (./script.sh or python script.py), well suited for automating recurring manual tasks.

Typical use cases

• Build scripts: orchestrate the actual compile/build process of a larger application (several steps: install dependencies, compile, test, package).
• Deployment scripts: automatically get a finished application onto a server, often as part of a CI/CD pipeline.
• Maintenance/migration scripts: one-off or rare tasks like a database schema change or a large file renaming.
• Cron jobs: regularly, automatically executed scripts (e.g. nightly backups, daily report generation).

The boundary with a “real application”

The boundary between a “script” and a “real application” is fluid and more a matter of convention than a technical line — a 20-line Python script for renaming files and a 50,000-line Python web application use the same language and the same interpreter, but differ considerably in scope, structure, error handling and maintenance requirements. Rule of thumb: as soon as a script needs error handling, automated tests, external configuration and several interconnected modules, it’s usually called an “application” rather than a “script”.

Pros and cons compared to compiled languages

Scripts are usually slower at runtime than compiled code (every line is interpreted when run, instead of being translated into efficient machine code in advance), but considerably faster to write and change — no separate compile step between a code change and a test run. For most automation tasks (that don’t run millions of times in a tight time loop), the development speed advantage clearly outweighs the runtime performance downside.

See also: Bash, PowerShell, Shell