Programming §
Programming studies how to specify computations precisely, how to transform specifications into executable programs, and how to structure programs for correctness, efficiency, and maintainability. It is relevant whenever a computation must be written, compiled, tested, or maintained.
Utility §
- It gives precise syntax and semantics to procedures.
- It maps programs onto memory, processes, and devices.
- It supports coordination across machines and users.
- It provides methods for proving correctness and detecting bugs.
Details
Programming sits between algorithmics and hardware: it takes the abstract procedure chosen by algorithmics and gives it a precise, machine-checkable form. The language specification defines what programs mean; the compiler transforms source into executable form; the runtime (OS, memory manager) executes the program on hardware. The boundary with algorithmics is: algorithmics asks “what is the procedure and what does it cost?”; programming asks “how do I write it so a machine can execute it, and how do I know it is correct?”. The boundary with hardware is: programming specifies the computation; hardware provides the substrate.
History §
- 1957: FORTRAN makes high-level languages and compilers practical.
- 1972: C provides a portable, low-level language for systems programming.
- 1978: Unix and C make operating systems portable.
- 2000s: Java, C#, and garbage-collected languages make memory safety the default for application development.
Classes §
| Page | Core object | Key metric | Boundary |
|---|---|---|---|
| Control flow and semantics | Statements, expressions, scope, closures, recursion | Expressiveness, type safety, predictability | What a program means; does not model how it is compiled or executed |
| Memory management | Stack, heap, allocators, garbage collectors | Allocation cost, GC pause, memory overhead | How memory is allocated and reclaimed; does not model the physical memory hierarchy |
| Language theory | Tokenizers, parsers, type systems, grammars | Parse time, type inference power, expressiveness | How source code is structured and checked; does not model the target architecture |
| Compilation | Compilers, linkers, AOT/JIT, bytecode | Compile time, code size, runtime performance | How source is transformed into executable form; does not model the OS or the network |
| Design patterns | Architectural and structural patterns | Coupling, cohesion, testability, maintainability | How to structure a program for long-term maintenance; does not model the algorithm or the hardware |
| Security | Memory safety, injection, authentication, authorization | Attack surface, exploitability, privilege level | How to protect a program from malicious input and misuse; does not model the cryptographic primitives themselves |
| Software engineering | Version control, testing, CI/CD, observability | Defect rate, deployment frequency, mean time to recovery | How to build, test, deploy, and monitor software at scale; does not model the algorithm or the hardware |
Authoritative sources