9. Other Important Programming Paradigms

In this chapter, we introduce additional programming paradigms that are significant in the field of computer science but have not yet been covered in this book.

Several paradigms covered in earlier chapters — functional (The Functional Programming Paradigm) and logic (The Logic Programming Paradigm) — are also broadly declarative. The paradigms discussed in this chapter either complement those (reactive, dataflow) or extend them in specific directions (AOP, constraint programming). Connections to earlier material are noted as they arise.

9.1. Declarative Programming

Declarative programming focuses on what the program should accomplish rather than detailing how to achieve it. SQL and XML, including HTML, are examples of declarative languages.

  • Focus: specify desired results rather than control flow.

  • Common uses: configuration, markup, query languages, and transformation languages.

  • Strengths: concise, closer to domain concepts, often easier to reason about correctness.

  • Weaknesses: can be less explicit about performance or control; tooling/optimization may hide important costs.

Example: SQL

SQL is a declarative query language for managing and retrieving data from relational databases.

SELECT name FROM students WHERE grade > 90;

Example: HTML

HTML is a declarative markup language for structuring and presenting content on the web.

<h1>Hello, world!</h1>

Example: XML and XSLT

XML is a markup language for encoding documents in a format that is both human-readable and machine-readable. While HTML is a specific instance of XML used for web content, XML itself is more general-purpose and can be used to represent a wide variety of data structures.

XSLT is a declarative language for pattern-driven, template-based transformation of XML documents into other XML, HTML, or text formats. Rather than writing imperative code to walk and manipulate a tree, you describe transformation rules and templates that match parts of the input.

XPath is a language for selecting nodes from an XML document. It is often used within XSLT to navigate XML structures.

<!-- students.xml (example input document) -->
<?xml version="1.0" encoding="UTF-8"?>
<students>
  <student id="s001">
    <name>Mary Smith</name>
    <grade>95</grade>
    <major>Computer Science</major>
    <email>mary.smith@example.edu</email>
    <enrolled>2023-09-01</enrolled>
  </student>
  <student id="s002">
    <name>John Doe</name>
    <grade>88</grade>
    <major>Mathematics</major>
    <email>john.doe@example.edu</email>
    <enrolled>2022-09-01</enrolled>
  </student>
  <student id="s003">
    <name>Alice Chen</name>
    <grade>92</grade>
    <major>Physics</major>
    <email>alice.chen@example.edu</email>
    <enrolled>2023-01-15</enrolled>
  </student>
</students>

<!-- transform.xslt (example stylesheet for transformation to HTML) -->
<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
  <xsl:template match="/">
    <html>
      <body>
        <h1>Students</h1>
        <ul>
          <xsl:for-each select="students/student[grade &gt; 90]">
            <li><xsl:value-of select="name"/></li>
          </xsl:for-each>
        </ul>
      </body>
    </html>
  </xsl:template>
</xsl:stylesheet>

9.2. Reactive Programming

Reactive programming is oriented around data streams and the propagation of change. It is commonly used in user interfaces and real-time systems.

  • Focus: streams of data, event propagation, and change propagation.

  • Common uses: UIs, dashboards, real-time analytics, and asynchronous workflows.

  • Strengths: models time-varying values naturally, simplifies composition of asynchronous events.

  • Weaknesses: mental overhead for reasoning about time and backpressure; debugging can be tricky.

Representative framework/library: RxJS (Reactive Extensions for JavaScript)

Note

RxJS is a library, not a language. The reactive paradigm is most clearly expressed at the language level in Elm (which enforces pure functional reactive programming) and in Haskell’s reactive-banana and reflex libraries. ReactiveX (Rx) is a cross-language API specification implemented as libraries for JavaScript (RxJS), Java (RxJava), Scala (RxScala), and many others.

Example (RxJS):

const clicks = fromEvent(document, 'click');
clicks.subscribe(() => console.log('Document clicked!'));

9.3. Aspect-Oriented Programming

Aspect-oriented programming (AOP) aims to increase modularity by allowing the separation of cross-cutting concerns, such as logging or security.

  • Focus: separate cross-cutting concerns from core logic via aspects and advice.

  • Common uses: logging, security, transaction management, and instrumentation.

  • Strengths: keeps core code cleaner; centralized handling of orthogonal concerns.

  • Weaknesses: can obscure control flow and make reasoning about behavior harder.

Paradigm-defining language: AspectJ

Example (AspectJ):

// Valid AspectJ syntax (compiled with ajc, the AspectJ compiler):
aspect LoggingAspect {
    before() : execution(* MyClass.myMethod(..)) {
        System.out.println("Method called!");
    }
}

Note

AspectJ extends Java syntax and requires the AspectJ compiler (ajc) rather than javac. For projects that use Spring, the equivalent Spring AOP annotation approach (@Aspect, @Before) is often preferred as it integrates with the standard Java toolchain.

9.4. Dataflow Programming

Dataflow programming models programs as a directed graph of the data flowing between operations, making it suitable for parallel and distributed computing.

  • Focus: data dependencies and flow rather than explicit control flow.

  • Common uses: signal processing, stream processing, and parallel computation (e.g., TensorFlow graphs).

  • Strengths: natural parallelism, clear depiction of dependencies.

  • Weaknesses: can be less intuitive for control-heavy logic; graph management can be complex.

Paradigm-defining language: LabVIEW, TensorFlow

Example (TensorFlow, Python):

import tensorflow as tf

# In TensorFlow 2.x, @tf.function defers execution as a computation graph,
# illustrating dataflow: c depends on a and b, not on control flow.
@tf.function
def add(a, b):
    return a + b

result = add(tf.constant(2), tf.constant(3))
print(result)  # tf.Tensor(5, shape=(), dtype=int32)

9.5. Event-driven Programming

Event-driven programming drives computation through events (user interactions, messages, timers) and callbacks. It is the dominant model in UI frameworks and server-side I/O (Node.js):

// Node.js HTTP server: execution is driven by incoming request events
const http = require('http');
const server = http.createServer((req, res) => {
  res.end('Hello, world!');
});
server.listen(3000);

// Browser: UI event drives a callback
document.querySelector('button')
  .addEventListener('click', () => alert('Button clicked!'));

Event-driven programming is closely related to the reactive paradigm (see above), with the key difference that reactive programming typically provides composable operators (map, filter, merge) over streams of events, whereas plain event-driven code uses ad-hoc callbacks.

9.6. Constraint Programming

Constraint programming extends logic programming by allowing variables to be constrained over a domain (e.g., integers, reals, finite sets) and using specialised solvers to find solutions. SWI-Prolog’s clpfd library is a widely used constraint solver:

:- use_module(library(clpfd)).

% Find two numbers X and Y that sum to 10 and are both between 1 and 9
solve(X, Y) :-
    X in 1..9,
    Y in 1..9,
    X + Y #= 10,
    label([X, Y]).

% Query: ?- solve(X, Y).
% X = 1, Y = 9 ; X = 2, Y = 8 ; ...

See also the discussion of Prolog and backtracking in The Logic Programming Paradigm.