Ping

Ping has no village-craft family origin — concrete objects don't have biographies. Loop, the mentor, introduces Ping by demonstration.

Loop hangs Ping on the workbench beside Bit, the robot the learner programs. "This is Ping," Loop says. "An event. It waits, silent, doing nothing — until its trigger happens. When the button is pressed, then it runs."

Loop attaches Ping to a button and writes on the note: `WHEN button pressed → Bit beeps`. Nothing happens. The bell hangs quiet. Then Loop presses the button — ping! — and Bit beeps, instantly. "See? It didn't run until the trigger. That's an event: when that happens, do this."

Loop demonstrates how Ping is different from Trek, the loop.

"Trek keeps going around, doing work over and over," Loop says. "Ping does nothing — until struck. It's not busy checking a thousand times a second. It rests, and the trigger wakes it." Loop shows the scaffolds: - Register a handler: say which trigger, and what to run when it fires. - Wait, using nothing: the event costs no effort while it waits. - Fire once per trigger: each press, each timer, each crossing rings it once. - Many bells at once: different events can wait for different triggers together.

"Ping doesn't decide anything," Loop says. "It doesn't think. It waits for one specific thing, and when that thing happens, it runs its code. That's all an event is."

Loop wires several events so the kid can build something that reacts.

The kid programs three Pings: `WHEN button pressed → Bit jumps`, `WHEN sensor covered → Bit lights up`, `WHEN 5 seconds pass → Bit spins`. All three bells hang quiet, waiting. The kid presses the button — Bit jumps instantly. Covers the sensor — Bit lights up. Waits — Bit spins on its own.

The kid laughs, delighted: Bit reacts the very instant each trigger fires, exactly when they make it happen. The program feels responsive, alive, quick.

Reflection: have you ever felt that pop of surprise and joy when something responded exactly when you triggered it?