Discussion:
Why can't Elm do back-in-time debugging anymore? (Subscriptions vs Signals)
(too old to reply)
John Bugner
2017-11-25 17:34:48 UTC
Permalink
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?
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Mike MacDonald
2017-11-25 18:39:59 UTC
Permalink
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?
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
John Bugner
2017-11-26 12:30:35 UTC
Permalink
(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?
--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...