

Elm Debugger: Stamps [video] - xkarga00
http://www.youtube.com/watch?v=zybahE0aQqA

======
wheatBread
The debugger has been available online for a while ( [http://debug.elm-
lang.org/](http://debug.elm-lang.org/) ). It explains how it works and has
some more interesting examples than stamps :)

------
hernantz
How is he able to rewind through time?

~~~
iamwil
He talks about how he does it here:
[https://www.youtube.com/watch?v=lK0vph1zR8s](https://www.youtube.com/watch?v=lK0vph1zR8s)

Basically, it's a consequence of Elm's design. All input to the program
(timers, mouse, keyboard, etc) comes from signals. Think of a signal as a
variable that changes over time. Each signal consists of events over time.

Because Elm's a pure functional language, there are no side effects, meaning,
if you put the same parameters into a function, you'll always get the same
result. That means if you put in the same event into the program, you'll get
the same result. If you record all events of the signals over time, you can
replay the state of the program at any time.

~~~
seanmcdirmid
Purity has little to do with it since the debugger isn't incremental in
replaying the events at all. Local program state is perfectly ok, for example,
since you are restarting from the first event anyways (otherwise nothing
physics would work), and there are well known ways of dealing with it
incrementally.

Swift's Playground, in contrast, is probably checkpointing in addition to
recording events given performance concerns (elm, being non incremental,
doesn't have a performance story for time travel). Note there is nothing pure
or monady about swift, which is not required for time travel debugging at all,
really.

~~~
iamwil
I don't understand your first sentence. What does "debugger isn't incremental"
mean?

And do you mean that purity has little to do with implementing this kind of
debugger in general? Or do you mean that purity is little to do with the Elm
debugger shown?

The question asked was, "how does the elm-debugger do this?" not "how do you
write this kind of debugger in general?" In answering the former, purity has
much to do with it, as I understood his talk.

~~~
seanmcdirmid
If you have 1,000 events, make one change to the code, then you must replay
all 1,000 events. If you are at event 999, and want to go back to 998, you
have to replay 998 events to get there. If it was incremental, you would have
much smaller chunks to compute in the average case.

Purity has little to do with implementing these kinds of debuggers, effects
need to be explicit, but this can be dynamic explicitness rather this static
kind.

The question can be interpreted in multiple ways, but this is not a feature
novel of Elm (see "time steering" in the 90s...and debuggers like xstep).

~~~
iamwil
I see where things are confused. In this case, I guess it depends on whether
you store the entire sequence of states of the application or if you're
storing the entire sequence of events emitted.

I was thinking of the former, while you were thinking of the latter. If the
entire state of the application is contained in one place, you don't need to
reply events from the beginning. You just need the application state at the
point.

