A function packages one transformation behind a clear interface: inputs enter, a result or side effect leaves, and the implementation can be tested independently.
Building interactive view…
Understand
Build the mental model
A function packages one transformation behind a clear interface: inputs enter, a result or side effect leaves, and the implementation can be tested independently. Prefer small functions with one responsibility, descriptive names, explicit inputs and testable outputs.
Click a stage to inspect what happens, what changes, and what should be checked before moving on.
Stage 1
Arguments
For the “Arguments” stage, identify the incoming object, the rule applied to it, the state change produced, and the evidence that would reveal a mistake. Technical context for Functions & Reusable Reasoning: Function parameters create local bindings; return values communicate results. Pure functions minimise hidden state, while side-effecting functions should make their effects explicit.
Practitioner checkpoint: Prefer small functions with one responsibility, descriptive names, explicit inputs and testable outputs.
What happens if…?
Break the assumption deliberately
Add hidden global state, then observe why the same call can stop producing the same result.
Move the control and explain what you expect before reading the visual.
Technical lens
Formalise what the visual is doing
Function parameters create local bindings; return values communicate results. Pure functions minimise hidden state, while side-effecting functions should make their effects explicit.
Technical questionUse a tiny case to make the mechanism observable. Function parameters create local bindings; return values communicate results. Pure functions minimise hidden state, while side-effecting functions should make their effects explicit. Verify one intermediate quantity, state change or mapping independently; then predict the consequence of this change: Add hidden global state, then observe why the same call can stop producing the same result.
Practitioner lens
Use it responsibly
Prefer small functions with one responsibility, descriptive names, explicit inputs and testable outputs.
Transfer testPrinting a result inside a function when the caller needs a returned value.
Worked exploration
Use the visual as an experiment, not decoration
Write a pure function add_tax(price, rate) that returns a value. Call it twice with the same inputs and verify the same output. Then contrast it with a function that silently reads a changing global tax rate.
Technical lens
Function parameters create local bindings; return values communicate results. Pure functions minimise hidden state, while side-effecting functions should make their effects explicit.
Practitioner check
Prefer small functions with one responsibility, descriptive names, explicit inputs and testable outputs.
Prediction before interaction
Add hidden global state, then observe why the same call can stop producing the same result.
Exploration walkthrough
Turn the interaction into an evidence trail
Write a pure function add_tax(price, rate) that returns a value. Call it twice with the same inputs and verify the same output. Then contrast it with a function that silently reads a changing global tax rate. Before moving the control, state your prediction. After the visual changes, name the specific state, statistic, boundary or mapping that changed and explain why that change is consistent—or inconsistent—with your prediction.
Record one observable quantity before the interaction and the same quantity afterwards.
Change one factor at a time so the causal effect of the control is inspectable.
Use an edge or failure case to discover where the concept stops behaving as the simple story suggests.
Static orientation diagram for Functions & Reusable Reasoning; use the interactive visual above to test how the relationships change.
Reference depth
Open the complete material
The flagship experience is the map. These pages contain the roads.
