Mutable versus Immutable history

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:

What really happened? What is the state of your system?

Explaining the ideal behavior of our notebooks is relatively simple: regardless of how you enter or edit cells, it should show the results of executing the file from top to bottom: the same way node does. The easiest way to accomplish this of course is to just re-run the entire document from the start after every change. This is in fact how the “rewind” feature in works in bpython. Of course, this quickly becomes unbearably slow with each additional cell you add, especially if the earlier cells are performing any networking or I/O. Additionally, if you had made use of any random variables, they would change right from under you with every change!

A different approach is to try to serialize the state of the runtime, such that you can unserialize it later to get things back to the same state. If you’ve ever worked in a pure functional programming language, you’re probably familiar with this strategy and it can be pretty successful. On an application level, it is trivial to simply save your top level immutable data structures, and rewind by simply loading an older one. However, in JavaScript it is non-trivial to even access the entire state of your program. Any variables trapped in a closure are by design completely opaque to the outside world, and thus can’t really be saved or restored. Additionaly, even in a pure functional context its difficult to store the state of things outside your application.