Shower thought on yesterday's thread above: the painter's algorithm is a way to make an interface less stateful. It lets you specify shapes to draw in any order. However: • It does this by adding more state to the implementation. You can't just draw each shape as you encounter it in the code. You have to shove them all into an array, sort by z value, and then draw them all. • It does this by adding more state to the communication channel. The human has to provide a z value now for each shape. Sometimes this is naturally obtained, sometimes it is not and the human now has to think in their heads about what z value to give their shapes to make the drawing come out as they want. Thinking about this, it feels like state is to some extent inevitable. There's some conservation of state going on. You can't really eliminate it. You squeeze it down in one area and like a balloon it pops up somewhere else.

"you have to shove them all into an array" — Well, painter's algo is just one solution; a z-buffer remembering the depth of previously painted pixels can truely allow drawing in any order, as you encouter them in the code. And by deciding per-pixel it avoids issues like occlusion cycles. Sure that doesn't "eliminate state", I added a whole-frame buffer! But conceptually I think of it as a much smaller departure than "record, sort, replay". Pedagogically I wouldn't get into either of this until the student (1) understands occlusion and paint order (2) feels that re-ordering code themselves (painter's algo being run in programmer's head not computer) got frustrating...

The err, if there is one, is forgetting that source order is state.

But is it hidden state?