When an access-log summary loop is rewritten as a chain of transformation stages, what bookkeeping does the chain remove?

An access log arrives as a sequence of lines and the job is a summary: how many requests ended in each response status. Almost everyone writes the loop version first, which is exactly why turning it into a chain of stages is such a common whiteboard exercise - the interviewer already knows what your loop looks like and is watching what you say about the swap. ## The three jobs hidden in one block A counting loop does three separate things inside a single body: - **Traversal** - reaching each line in turn, typically by moving an index from the first position to the last and testing it every time round. - **Selection** - deciding which lines take part, usually as a guard in the body that skips malformed or out-of-scope records. - **Accumulation** - folding whatever survives into a growing result, here a table from status to count. Only selection and accumulation are the problem you were asked to solve. Traversal is mechanism: it is how this language reaches the elements of a collection, and it is identical in every loop anyone has ever written over one. Because all three jobs share one block, a reader has to pull them apart mentally before they can say what the code computes, and every reader pays that cost again. ## The same summary, said as stages The chain names each remaining job once and lets the stages do the walking: keep the well-formed lines, take each line's status, count how often each status occurs. Nothing names a position, nothing tests a bound, nothing holds a partially built table. | Job in the loop | Where it goes | What disappears with it | |---|---|---| | Move and test the index | into the stages themselves | the index variable, its start, its bound, its advance | | Skip guard inside the body | a keep-only stage | a negated condition buried mid-body | | Add one to a table entry | a counting stage | a mutable table observable half-built | ## What the rewrite actually buys 1. **Intent sits on the surface.** Each stage is one sentence of the specification. A reader checks three short claims instead of simulating a traversal in their head, and a wrong claim is wrong in an obvious place. 2. **A whole family of boundary mistakes has nowhere to live.** Starting one position late, stopping one element short, reading past the final line, advancing the index on the counted path and forgetting it on the skip path - every one of these is a mistake *about the index*, and there is no longer an index. This is why the rewrite can be worth doing even when the loop was correct: the next edit cannot reintroduce them. (A stage that genuinely needs a neighbour puts one boundary decision back, but it is a single decision made in the open rather than arithmetic that has to be right on every path.) 3. **No half-built intermediate state.** In the loop, the counting table exists in scope, incomplete, for the whole traversal; anything else in the body can read it or write it. In the chain, the accumulation belongs to the counting stage and is observable only when finished. 4. **The work becomes describable in pieces.** Each stage's step is stated for one element with no reference to position, so the same summary can in principle be computed over chunks and the chunk results combined. Whether anything actually does that is a property of the machinery underneath; the rewrite makes it expressible, not automatic. ## What it does not buy - **Correct meaning.** Reading the wrong field, keeping the wrong lines, or counting requests when the question asked for transferred bytes survives the rewrite untouched. A chain makes wrong intent legible; it cannot make intent right. - **Speed.** Nothing about the shape guarantees it. Some machinery collapses adjacent stages into a single pass; some materialises a fresh collection between every stage. Say that it depends rather than claiming a win. - **The accumulator.** Counting still needs a starting value and a step that combines one element into the result so far. Those moved *inside* the counting stage; they did not vanish. A candidate who says "the chain has no state" is describing visibility, not computation. - **Per-line stepping.** The loop had one numbered body line a debugger could stop on once per element. The chain has stages, and the debugging unit becomes the stage. ## How to answer it in an interview Name the three jobs, say which one the stages take over, and name what left with the index. Then volunteer the honest half: the accumulation moved rather than disappeared, the speed question is open, and the per-element breakpoint is gone. Interviewers ask this to find out whether your style is a choice or a habit, and a candidate who can only recite the benefits usually rewrote the loop because a style guide said to.