in that case, without adding impure statefulness, how does one differentiate between "a paused frame is being displayed" and "an intermediate frame of a playing video is being displayed"
--
then at the end, the example from elm looks great, but i see lots of impure state being generated (browser, model) or am i missing something?
A "paused" frame could be represented like Fi, Fi+1 ... Fi+N, etc; for every moment i..(i+N), F remains the same and is thus "paused." The thing that's tough to wrap your head around is our language is rooted in object-orientation however. "Pause" is less of a meaningful term when time is discretized. See also https://softwarefordays.com/post/fp-as-a-scientific-revoluti...
i guess what i was thinking was, if there was a ui, with a play/pause icon, and playing the video should cause the play icon to switch to a pause icon (because video is now "playing" so we want to be able to click it and "pause" the video) how do we represent that in a purely functional way?
since at any "timeless" instant, t1 vs t2 is just a frame1 vs frame2 issue at the language level (?), how in a purely functional world, would we determine that video is indeed playing and that icon should be swapped while playing vs not?
does user-interactive systems imply that there must inherently be some impurity?
All functional programs (even if written in Haskel) have side effects - the CPU only has a certain amount of registers that can be used, for example, so any nontrivial program will be constantly overwriting them. That elm program however only exposes pure functions in user land, just like with a Haskel program
You have a paused "state" if that's relevant to you. But you can say "the video pauses at time t1" and "the video resumes at time t2", rather than restricting yourself to "the video is paused" or "the video is not paused".
Well then there is something fundamentally different about the video between T1 and T2 vs after T2. That is state - paused or playing. Word games don't change that.
This fact is unfortunate for OO aficionados who try to build programs by modelling the real world, because it leads them to build programs with the same problem. Whereas FP aficionados realise that even though there's no "undo" in the real world, we can enable it in our programs.
Only from the inside ;)
