Program Outputs and Flow of Control

Press the same button twice and you can get two different results, because the program is not just reacting to your click, it's reacting to your click plus whatever it already remembers. That memory is called state: values stored in variables that persist across actions. A counter program doesn't just know you clicked, it knows you clicked while already sitting at 7. Output is really a function of two things together, current state and new input, and flow of control is the sequence of steps the program follows to combine them.

Flow of control usually runs top to bottom, but it bends: a condition can skip a block, a loop can repeat one, an event like a click can jump execution to a handler that updates state immediately. Each time that handler runs, it reads the existing variable, changes it, and writes the new value back, so the next click starts from a different place than the last one did. A reset is just another instruction in that flow: it overwrites state back to a known value, breaking the chain so later input no longer depends on earlier input.

This matters beyond single programs. The variables a program keeps are its data abstractions, the meaningful quantities it tracks to represent something real, like a score or a total. Output is only trustworthy if that internal state is managed on purpose: reset when it should be, preserved when it shouldn't be. Leftover state that nobody resets is one of the most common sources of a program that 'used to work' and then mysteriously doesn't.