|
|
|
|
|
by rybosome
4453 days ago
|
|
As they note in the section entitled "How Elm Makes this Possible", the design of the language lends itself to this feature. Functional purity and immutability mean that functions can be evaluated speculatively, as demonstrated in the video where Mario's jump trajectory is altered as the gravitational force is weakened or strengthened. There is no need to save any state beyond the user inputs (mouse position and clicks, keys pressed) and the time at which they occurred. Once saved, they can be reevaluated safely (due to the purity and immutability), and live-modifying the code or adjusting the time is a simple matter of rerunning. It's a wonderfully designed feature, but the ability to implement with relative ease is a natural consequence of strict FRP. In an impure, mutable, stateful language this would be quite challenging, and potentially dangerous. Given a line of code that spawns a thread, for instance, how would it be made clear that the inverse of this state is shutting the thread down? What if the thread has already modified shared memory - how will you track that? If you were to attempt to preserve the entire state of the running program (threads, open files, etc.), how would you quickly reproduce it upon modification? |
|