2. Context and Background

In this chapter, we establish a practical context and provide some background information for the study of programming languages.

Note

Key terms used in this chapter:

  • Functional requirement (FR): a specification of what the system must do — the mapping from inputs to outputs or observable behaviours.

  • Nonfunctional requirement (NFR): a quality attribute of the system itself, such as testability, performance, reliability, or maintainability.

  • Refactoring: improving the internal structure of code without changing its external behaviour. Refactoring improves NFRs such as maintainability and testability.

  • Continuous integration (CI): the practice of automatically building and testing the system each time code is committed, catching integration errors early.

  • Programming paradigm: a fundamental style of programming that reflects a model of computation. Different paradigms provide different abstractions; see the Programming language history and paradigms section below.

2.1. Software requirements

In most cases, we develop software to provide some form of value:

  • learn a language, library, framework, platform, technique, or tool (see also the ThoughtWorks Technology Radar)

  • solve a problem

  • produce an asset

There is usually some tension among these three activities.

The basic categories of requirements are

  • functional (FR)

    • output as function of input: y = f(x)

    • or some other description of observable behavior

      • batch

      • interactive/event-based

  • nonfunctional (NFR): additional properties of f, e.g.

    • testability

      • most important nonfunctional requirement

      • allows testing whether functional requirements are met

      • good architecture often happens as a side-effect (APPP pp. 36-38), such as separating I/O from core functionality

    • performance

    • scalability

      • e.g. performance for large data sets: asymptotic order of complexity

      • (big-Oh) in terms of input size n

    • reliability

    • maintainability

    • static versus dynamic NFRs

Several common questions and issues related to requirements arise:

  • how do requirements relate to the project development lifecycle?

  • BUFD versus MVP

  • how do testing and refactoring relate to requirements?

The following figure by Kazman relates unit operations (high-level generalizations of refactorings) to software quality factors (nonfunctional requirements). Each arrow indicates that applying the unit operation (e.g., modularize, abstract) tends to improve the corresponding quality factor (e.g., maintainability, testability). Notably, modularize simultaneously improves both maintainability and testability.

Kazman diagram showing unit operations (generalised refactorings) mapped to the software quality factors they improve

Kazman et al.: unit operations and the quality factors they improve.

As we will see throughout the course, programming language features directly support or hinder the satisfaction of NFRs. Static type systems improve reliability by catching errors at compile time. Immutability and pure functions improve testability by eliminating hidden state. Built-in concurrency primitives improve scalability. The language design chapters will repeatedly refer back to these requirements as motivation for language features.

2.2. Overview of a lightweight development process

A successful development process usually comprises these minimal elements:

  • automated regression testing

    • tests represent expectations of how the software should behave

    • when expressed as code, these are

      • fun to produce (like other coding)

      • convenient to run frequently

    • fix system-under-test (SUT) (not tests themselves) until tests pass

    • retest every time

      • a feature is added

      • the code is refactored

  • refactoring

    • improve the quality of the code without changing its behavior

      • macro level: nonfunctional requirements (quality factors)

      • micro level: code smells

    • catalog of refactorings

  • continuous integration

The process tree example illustrates continuous integration using various hosted services:

The click counter example includes additional hosted continuous integration and delivery targets suitable for mobile app development.

2.3. Software design principles and patterns

The software development community has identified various principles intended to guide the design and development process, for example:

  • DRY (don’t repeat yourself)

  • SoC (separation of concerns)

  • SOLID

The community has also developed a body of design patterns that represent reusable solutions to recurring problems. Some key design patterns we will rely on in this course include

  • Iterator

  • Strategy

  • Command

  • Composite

  • Decorator

  • Visitor

  • Abstract Factory

  • Observer

We will recap these throughout the course as needed.

Note

Language-specific design patterns are called idioms.

2.4. Programming language history and paradigms

The resources in this section cover fundamental models of computation, language paradigms, and language principles.

A programming paradigm is a fundamental style or approach to programming that reflects a mental model of computation. It determines what abstractions are available, how state and control flow are managed, and what kinds of problems a language is best suited for. Peter Van Roy’s paradigm diagram (linked above) organises over 30 paradigms by their core features.

The major paradigms covered in this course are:

  • Imperative (The Imperative Programming Paradigm): computation as a sequence of state-changing statements; the dominant paradigm in languages like C, Java, and Python.

  • Object-oriented (The Object-Oriented Programming Paradigm): computation modelled through objects that encapsulate state and behaviour; extends the imperative paradigm with encapsulation, inheritance, and polymorphism.

  • Functional (The Functional Programming Paradigm): computation as the evaluation of mathematical functions; emphasises immutability, higher-order functions, and algebraic data types; exemplified by Haskell, Scala, and Clojure.

  • Logic (The Logic Programming Paradigm): computation as logical deduction; programs are sets of facts and rules and execution is query-driven; exemplified by Prolog.

  • Concurrent (The Concurrent Programming Paradigm): computation as multiple simultaneous activities; raises issues of synchronisation, shared state, and nondeterminism.

A foundational theoretical result bounds all of these paradigms: the Church-Turing thesis states that every effectively computable function can be computed by a Turing machine (or equivalently, by a lambda calculus expression, or by a recursive function). A language capable of expressing every Turing-computable function is called Turing complete. Understanding this equivalence helps explain why paradigms differ in expressiveness of style but not in fundamental computational power.

2.5. Popularity indices and performance comparisons

There are a number of programming language popularity indices and performance comparisons. Before drawing any conclusions from these indices, it is important to understand their methodology.

Note

When consulting any popularity or performance index, ask: What is the data source? (search queries, job postings, GitHub commits, or benchmark runs each capture different things.) What counts as “a language”? (Some indices conflate dialects or treat Jupyter notebooks as Python.) Does the index weight by project size or contributor count? Understanding methodology prevents over-interpreting rankings. The PYPL and TIOBE indices publish their methodology; always read it before drawing conclusions.