Possible Extensions

What if code examples weren't just illustrations, but executable? The reader encounters:

state_2 = apply_move(state_1, knight g1 → f3)

And can run it. See the board change. Modify the move. Watch what happens.

This requires:

The reader doesn't just read about immutability---they experience it, watching both states coexist on screen.

• A formal pseudo-language: Our notation, currently informal, becomes a real (if minimal) language with parser and interpreter
• Live execution environment: Browser-based REPL that understands our language
• State visualization: Chess boards, data structures, and flow diagrams render automatically from program state

Currently, our TikZ diagrams are hand-crafted. But they follow patterns: function boxes, arrows for data flow, branching for conditionals.

A tool could:

1. Parse the pseudo-code's AST (Abstract Syntax Tree)
2. Recognize patterns: function application, composition, branching
3. Generate corresponding flow diagrams automatically

// This code...
result = pick_random(get_legal_moves(state))

// ...automatically generates a diagram:
// state → [get_legal_moves] → moves → [pick_random] → result

Benefits: diagrams stay synchronized with code, readers can toggle between views, the visual language becomes systematized.

Our "Try It Yourself" sections currently ask questions into the void. The reader thinks, but receives no feedback.

An AI layer could:

• Evaluate attempts: Reader submits their model of Tic-Tac-Toe state; AI assesses completeness and suggests refinements
• Adapt difficulty: Struggling readers get simpler challenges; advanced readers get deeper problems
• Explain mistakes: Not "wrong"---but "here's what happens if we try your approach..."
• Generate variations: Infinite practice problems following the same patterns

The book becomes a dialogue, not a monologue.

Currently we use:

• Pseudo-code: Informal, readable, but imprecise
• Natural language: The left column of our split-view
• Diagram notation: TikZ-based visual language
• Chess notation: Our explicit piece + square format

A rigorous treatment would:

1. Define formal grammars for each notation
2. Establish semantic mappings between them (pseudo-code $\leftrightarrow$ diagram)
3. Create tooling that validates consistency
4. Enable translation: reader preferences for notation style

This transforms the book from "teaching aid" to "specification"---a foundation others can build upon.

Our pseudo-code abstracts away syntax. But readers eventually work in real languages.

A generation layer could show equivalent code in:

• Python (imperative, readable)
• JavaScript (ubiquitous, functional features)
• Haskell (pure functional)
• Rust (systems, ownership model)
• Clojure (Lisp, immutable by default)

The reader sees that map is the same idea whether it's list.map(f) or map f list or (map f list).

Features for shared exploration:

• Margin annotations: Reader notes visible to others (opt-in)
• Exercise discussions: See how others approached the same problem
• Concept voting: Which explanations resonate? Which confuse?
• Community examples: Reader-submitted illustrations of concepts

Concepts introduced in Chapter 3 may fade by Chapter 15. Integration with spaced repetition systems (Anki, etc.) could:

• Generate flashcards from key concepts
• Schedule review of earlier material
• Track reader's retention across the conceptual graph

When prose references a term defined in nearby code, the reader must search for the connection. What if we made it visible?

Imagine: when the text mentions apply_move, a subtle line extends from that word to the function definition in the code block---curving up or down, connecting explanation to implementation.

This requires:

In an interactive web version, this becomes even more powerful:

• Named anchors: Both code definitions and prose references must be addressable
• Position awareness: Knowing where elements land on the page, even across page breaks
• Graceful rendering: Lines that curve naturally, don't obscure content

\marginnote{The static book uses color (\textbackslash coderef{name}) to hint at the connection. The interactive version would make it literal.}

• Hover to reveal: Mouse over apply_move in the prose, and a line animates to the function definition in the code block
• Bidirectional: Hover over a function in code, see all prose references highlight
• Click to navigate: The connection becomes a link

The effect: the conceptual connection becomes visible. The reader sees not just what relates, but how it relates spatially. In print, we suggest; on screen, we show.

Ultimately, these extensions point toward a different artifact entirely: not a book, but a system. A system that:

• Executes its own examples
• Generates its own diagrams
• Converses with its readers
• Evolves through community contribution
• Adapts to individual learning paths

The static book you hold is a snapshot. These extensions sketch the dynamics it might acquire.

If you're interested in contributing to any of these directions, the source of this book lives at:

github.com/javifernandes/progbook