[elm-discuss] Why can't Elm do back-in-time debugging anymore? (Subscriptions vs Signals)

[John Bugner]

In Elm 0.17, signals were removed, and subscriptions were added. Evan says

That is all nice, but the big benefit is that Elm is now significantly

easier to learn and use.
I agree! Thinking about my program in terms of MVU (model, view, update) is
easier than trying to put together a signal graph. I'm told that this
change broke things like back-in-time debugging, but I don't know why. Why
is it not possible anymore? It seems that subscriptions grew out of this
successful experiment
( https://github.com/evancz/start-app/blob/master/src/StartApp.elm ) to
find a way to simplify programming with signals.

Let's compare the signatures of the 'Program' types ('Config' in

type alias Config model action =
{ init : (model, Effects action)
, update : action -> model -> (model, Effects action)
, view : Signal.Address action -> model -> Html
, inputs : List (Signal.Signal action)
}
{ init : (model, Cmd msg)
, update : msg -> model -> (model, Cmd msg)
, subscriptions : model -> Sub msg
, view : model -> Html msg }
}
-> Program Never model msg

They look pretty similar! 'init' is the same. 'update' is the same. But
'view' and 'subscriptions'/'inputs' are different. 'view' lost a parameter,
and 'subscriptions' gained a parameter. The magic difference that lost us
BiT debugging must be in there, right? I recall reading that BiT debugging
was only possible when the signal graph was static. Wouldn't this
correspond to 'subscriptions' gaining a parameter? (and thus becoming
dynamic?) and about 'view', why did it have/need a 'Signal.Address action'
parameter?

I guess my question is: wouldn't it have been possible to make Elm use the
MVU model, but still allow BiT debugging? (Basically keep using the
StartApp package?) If so, why then was FRP abandoned?

[Mike MacDonald]

It still supports most of the old time-travel functionality; the only thing
gone is the ability to resume execution from a historical state. I do not
think this is a technical limitation, but rather a decision made to
simplify the debugging workflow. (Also, import/export is a super valuable
feature for QA.)

Post by John Bugner
In Elm 0.17, signals were removed, and subscriptions were added. Evan says

That is all nice, but the big benefit is that Elm is now significantly

easier to learn and use.
I agree! Thinking about my program in terms of MVU (model, view, update)
is easier than trying to put together a signal graph. I'm told that this
change broke things like back-in-time debugging, but I don't know why. Why
is it not possible anymore? It seems that subscriptions grew out of this
successful experiment (
https://github.com/evancz/start-app/blob/master/src/StartApp.elm ) to
find a way to simplify programming with signals.
Let's compare the signatures of the 'Program' types ('Config' in

type alias Config model action =
{ init : (model, Effects action)
, update : action -> model -> (model, Effects action)
, view : Signal.Address action -> model -> Html
, inputs : List (Signal.Signal action)
}
{ init : (model, Cmd msg)
, update : msg -> model -> (model, Cmd msg)
, subscriptions : model -> Sub msg
, view : model -> Html msg }
}
-> Program Never model msg

They look pretty similar! 'init' is the same. 'update' is the same. But
'view' and 'subscriptions'/'inputs' are different. 'view' lost a parameter,
and 'subscriptions' gained a parameter. The magic difference that lost us
BiT debugging must be in there, right? I recall reading that BiT debugging
was only possible when the signal graph was static. Wouldn't this
correspond to 'subscriptions' gaining a parameter? (and thus becoming
dynamic?) and about 'view', why did it have/need a 'Signal.Address action'
parameter?
I guess my question is: wouldn't it have been possible to make Elm use the
MVU model, but still allow BiT debugging? (Basically keep using the
StartApp package?) If so, why then was FRP abandoned?

[John Bugner]

(1) What do you mean by "gone"? Impossible?, or simply not included?
(2) Isn't "resuming execution from a historical state" the same thing as
importing a state?

Post by Mike MacDonald
It still supports most of the old time-travel functionality; the only
thing gone is the ability to resume execution from a historical state. I do
not think this is a technical limitation, but rather a decision made to
simplify the debugging workflow. (Also, import/export is a super valuable
feature for QA.)

Post by John Bugner
In Elm 0.17, signals were removed, and subscriptions were added. Evan

That is all nice, but the big benefit is that Elm is now significantly

easier to learn and use.
I agree! Thinking about my program in terms of MVU (model, view, update)
is easier than trying to put together a signal graph. I'm told that this
change broke things like back-in-time debugging, but I don't know why. Why
is it not possible anymore? It seems that subscriptions grew out of this
successful experiment (
https://github.com/evancz/start-app/blob/master/src/StartApp.elm ) to
find a way to simplify programming with signals.
Let's compare the signatures of the 'Program' types ('Config' in

type alias Config model action =
{ init : (model, Effects action)
, update : action -> model -> (model, Effects action)
, view : Signal.Address action -> model -> Html
, inputs : List (Signal.Signal action)
}
{ init : (model, Cmd msg)
, update : msg -> model -> (model, Cmd msg)
, subscriptions : model -> Sub msg
, view : model -> Html msg }
}
-> Program Never model msg

They look pretty similar! 'init' is the same. 'update' is the same. But
'view' and 'subscriptions'/'inputs' are different. 'view' lost a parameter,
and 'subscriptions' gained a parameter. The magic difference that lost us
BiT debugging must be in there, right? I recall reading that BiT debugging
was only possible when the signal graph was static. Wouldn't this
correspond to 'subscriptions' gaining a parameter? (and thus becoming
dynamic?) and about 'view', why did it have/need a 'Signal.Address action'
parameter?
I guess my question is: wouldn't it have been possible to make Elm use
the MVU model, but still allow BiT debugging? (Basically keep using the
StartApp package?) If so, why then was FRP abandoned?