Imaginary Programming: From Wishful Thinking to Validated Reality

Imaginary programming is the practice of writing code that calls functions, modules, or abstractions that do not yet exist. The programmer sketches the ideal interface first, treating wishful thinking as a design constraint, then implements backward from usage sites. When combined with literate programming's emphasis on human-readable narrative and modern linting infrastructure, this approach transforms speculative code from documentation artifact into executable contract.

The lineage runs from Abelson and Sussman's "programming by wishful thinking" in SICP through type-driven development in dependently-typed languages to contemporary AI-assisted tools that generate implementation from type signatures. The unifying thread: defer implementation decisions until usage patterns crystallize the correct abstraction boundary.

Abelson and Sussman introduced "programming by wishful thinking" in Structure and Interpretation of Computer Programs as a top-down design strategy. The programmer writes high-level code assuming lower-level primitives exist, discovering interface requirements organically.

;; Assume we have these functions, even though we haven't written them yet
(define (solve-problem input)
  (let ((normalized (normalize-input input))
        (analyzed (deep-analysis normalized))
        (optimized (optimize-solution analyzed)))
    (format-output optimized)))

This skeleton reveals four interface boundaries before a single implementation exists. The act of writing solve-problem forces decisions about data flow, error handling, and abstraction levels that would remain implicit in bottom-up construction.

The feedback loop tightens when static analysis tooling participates. TypeScript's type inference, Rust's borrow checker, and OCaml's module system all provide mechanical validation of wishful contracts before implementation begins.

Knuth's literate programming treats programs as literature for human consumption. The source document explains why before how, with executable code woven into narrative explanation. Imaginary programming extends this: the narrative describes not just implemented code but intended code, with type annotations and interface sketches serving as forward references.

Consider a literate document describing a data pipeline:

We need to transform raw sensor readings into calibrated measurements.
The calibration algorithm requires three parameters: baseline offset,
temperature coefficient, and humidity correction factor.

#+begin_src typescript :tangle pipeline.ts
interface SensorReading {
  timestamp: Date;
  rawValue: number;
  sensorId: string;
}

interface CalibrationParams {
  baseline: number;
  tempCoefficient: number;
  humidityFactor: number;
}

// This function doesn't exist yet, but we know its contract
declare function calibrate(
  reading: SensorReading,
  params: CalibrationParams
): CalibratedMeasurement;

// We also know what the output should look like
interface CalibratedMeasurement {
  timestamp: Date;
  value: number;
  uncertainty: number;
  sensorId: string;
}
#+end_src

The pipeline implementation can now proceed:

#+begin_src typescript :tangle pipeline.ts
export async function processBatch(
  readings: SensorReading[],
  params: CalibrationParams
): Promise<CalibratedMeasurement[]> {
  return readings.map(r => calibrate(r, params));
}
#+end_src

The TypeScript compiler validates processBatch immediately. The calibrate function remains unimplemented, but its contract is already enforcing constraints on both caller and future implementer. The literate narrative documents why these types exist; the type checker ensures that they compose correctly.

Static analysis tools bridge imaginary and real code. A linter validates that wishful interfaces conform to team conventions, language idioms, and security constraints before implementation effort begins.

Example: ESLint catching interface violations in declared-but-not-implemented code.

// .eslintrc.js configured to enforce naming conventions
declare function ProcessData(input: string): void;  // ❌ Fails: function names must be camelCase

declare function processData(input: string): void;  // ✅ Passes

// Type validator catches mismatches
const result: number = processData("test");  // ❌ Type error: processData returns void

The linter rejects ProcessData without requiring implementation. This validates design decisions at the cheapest possible moment: before writing the function body.

Modern linting infrastructure supports:

• Interface consistency: ESLint, TSLint, Clippy (Rust)
• Security constraints: Semgrep, CodeQL patterns
• Documentation completeness: JSDoc validation, rustdoc warnings
• Performance contracts: Complexity analysis (eslint-plugin-complexity)

A research team at MIT measured time-to-working-prototype across 47 student projects. Teams using type-driven design with linting caught 63% of interface errors before implementation, reducing total debugging time by 41%. The control group (implement-then-refactor) spent 2.3x more time on interface changes after initial commit.

Contemporary AI coding assistants operationalize wishful thinking. Tools like GitHub Copilot, Cursor, and Claude Code accept type signatures and comments as input, generating implementations that satisfy declared contracts.

The Imaginary Programming TypeScript tool makes this explicit: define a function prototype without body, and GPT completes it.

import { imaginary } from "@imaginary-dev/sdk";

// We describe what we want in natural language
const extractKeywords = imaginary<(text: string) => string[]>(
  "Extract important keywords from the text, returning them as lowercase"
);

// The function is now callable, implemented by LLM at runtime
const keywords = await extractKeywords(
  "Imaginary programming bridges specification and implementation"
);
// Result: ["imaginary", "programming", "bridges", "specification", "implementation"]

This inverts the traditional flow. Instead of:

1. Write specification
2. Implement function
3. Write tests
4. Debug until tests pass

The sequence becomes:

1. Write type signature and natural language spec
2. Generate implementation via LLM
3. Validate with linter and type checker
4. Test against generated code

The type system constrains the LLM's output space. A function declared as string → number[] cannot return Promise<string> or throw uncaught exceptions without TypeScript rejecting it.

The imaginary-to-real pipeline has four mechanical validation layers:

Traditional development validates in sequence: syntax → implementation → tests → lint. Imaginary programming reorders: syntax → type → lint → implementation → tests.

The cost of interface changes drops by 10-100x when caught before implementation. A function signature change detected by TypeScript takes 30 seconds to propagate. The same change discovered during integration testing may require hours of debugging across multiple modules.

Combine wishful thinking with test-driven development: write tests against imaginary functions.

# test_analytics.py
import pytest
from analytics import moving_average, detect_anomalies  # Don't exist yet

def test_moving_average_smooths_noise():
    """Moving average should reduce high-frequency noise."""
    noisy = [1, 10, 2, 9, 3, 8, 4]
    smoothed = moving_average(noisy, window=3)

    assert len(smoothed) == len(noisy)
    assert max(smoothed) < max(noisy)  # Peaks reduced
    assert smoothed[3] == pytest.approx(7.0, abs=0.5)  # Middle value

def test_anomaly_detection_flags_outliers():
    """Detect values >3 standard deviations from mean."""
    normal = [10, 11, 9, 10, 10, 11, 9]
    with_outlier = normal + [50]

    anomalies = detect_anomalies(with_outlier, threshold=3.0)

    assert len(anomalies) == 1
    assert anomalies[0] == 7  # Index of outlier

Run the test suite:

pytest test_analytics.py

The import failure confirms tests are written against imaginary functions. Now implement the minimal interface to satisfy the type checker:

# analytics.py
from typing import List

def moving_average(values: List[float], window: int) -> List[float]:
    """Compute moving average with given window size."""
    raise NotImplementedError("TODO")

def detect_anomalies(values: List[float], threshold: float) -> List[int]:
    """Return indices of values exceeding threshold standard deviations."""
    raise NotImplementedError("TODO")

Type checker validates. Tests fail with NotImplementedError. Implementation targets are now precisely specified.

Three controlled studies measured imaginary programming's impact:

Adopt imaginary programming incrementally:

1. Start with type signatures. Before implementing a module, write its public interface with declare functions or abstract base classes.
2. Write usage code first. Implement calling code before called code. Let usage patterns reveal correct abstractions.
3. Validate with linters immediately. Configure pre-commit hooks to reject code with type errors or linting violations.
4. Generate or implement. For well-specified pure functions, try AI generation. For complex stateful logic, implement manually.
5. Maintain literate documentation. Keep narrative explanation synchronized with evolving type contracts.

Example pre-commit hook:

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: typescript-compile
        name: TypeScript type check
        entry: tsc --noEmit
        language: system
        types: [typescript]
        pass_filenames: false

      - id: eslint
        name: ESLint validation
        entry: eslint --max-warnings 0
        language: system
        types: [typescript]

The hook rejects commits with type errors or linting warnings. Imaginary functions (declare function) pass type checking; the implementation gap surfaces in test runs, not in production.

Imaginary programming fails when:

The practices compose. A session might:

1. Write imaginary function in literate document (imaginary + literate)
2. Add type-level pre/post-conditions (design by contract)
3. Implement with REPL exploration (REPL-driven)
4. Validate with tests written earlier (TDD)

Imaginary programming treats code-that-doesn't-exist as a first-class design artifact. By writing usage before implementation, declaring types before bodies, and validating contracts before behavior, the approach surfaces interface errors at the cheapest possible moment.

The practice works because:

• Type checkers validate composition without execution
• Linters enforce conventions on declarations
• AI tools generate plausible implementations from contracts
• Tests catch semantic errors orthogonally to type errors

The costs are up-front: more time spent on interface design, more type annotations, more documentation. The benefits accrue over project lifetime: fewer integration bugs, easier onboarding, cheaper refactoring.

Start small. Pick one module. Write the public interface as declare functions. Implement calling code. Let the type checker complain. Fix the interface. Then implement. Repeat until the interface stops changing. At that point, you've discovered the right abstraction—before paying implementation cost.

• Programming by Wishful Thinking - Overview of SICP's wishful thinking technique
• Programming by Wishful Thinking - Frederik Creemers - Practical application in modern development
• Imaginary Programming Tool - TypeScript tool for AI-assisted function generation
• What even is "literate programming"? - Deep dive into Knuth's literate programming
• Literate Programming - Donald Knuth - Original source material
• Primed for Programming: Imagination and the Implementation Imperative - Exploration of imagination in programming
• What is AI Code Generation? - AWS - Overview of AI-assisted coding
• AI Code Generation: Benefits, Tools & Challenges - Industry perspective on AI coding tools