> The Simulation actually has a bug. If you resize the window to be smaller you can trap the DVD logo on an edge. Resizing the window in the Animation solution means we recalculate to the correct position.
Hmmm....that depends on what you define as the "correct" position. With the stateless version, any resizing of the window will cause the logo to instantaneously jump to where it would have been, and start moving in the direction it would have been, if the window had been the new size all along.
Is that the correct behaviour though? Or would you want the logo to keep moving from it's current position, in it's current direction, if that were possible?
You provide a good hook for the point I want to make, which is that while I agree that many developers underestimate the cost of state, sometimes people can overreact and overestimate its costs too. Less common, as underestimation is still the common case, but it can be done.
I treat it as a cost that needs to be managed and that we want to make sure to exploit its advantages for those costs, but it is still often still something that is better in the system.
In this case, a hybrid approach can be useful. Writing the animation in terms of the initial state and the time is quite useful and powerful on its own terms, something worth doing. On the other hand, dealing with an event stream of changing resolutions, while possible, also nukes all the cleanliness out of the solution. So what do we do? When the window resizes, reseat the original parameters. The animation as written implicitly starts at 0,0 and has an implicit direction in it. Bringing those out as parameters isn't a bad idea anyhow, because that may not be the ideal. Then, when the window resizes, simply look at the current parameters and start a new animation with those as the initial state, handling problems with window becoming too small or something as some simple checks on the initial parameter.
This yields a nice mix of both the advantages of statelessness and the advantages of state. It's a continuum rather than a binary, and the optimum is not always the extrema. Sometimes it is, but not always.
You could fix this by deriving the function from some initial state, and then when resizes occur you just take a snapshot of the current animation state, freeze the animation until resizing stops, and replace the function with a new one derived from your previous initial state. So this does require _some_ state but only to initialize.
Hmmm....that depends on what you define as the "correct" position. With the stateless version, any resizing of the window will cause the logo to instantaneously jump to where it would have been, and start moving in the direction it would have been, if the window had been the new size all along.
Is that the correct behaviour though? Or would you want the logo to keep moving from it's current position, in it's current direction, if that were possible?