Evan Czaplicki: A Farewell to FRP
This is old news, I know, but here's my comment for anyone interested:
When it was announced that Elm is dropping FRP, I removed the Elm section from the book.
I haven't used Elm much, but my understanding from Evan's (old) presentations that I've seen is that he favours a model where there's a data structure containing the state of the game, and it gets processed through an update method, for example, something like this:
update :: MouseEvent -> GameState -> GameState
What this does is to separate state right out from logic, and this is the essence of functional programming. Imperative programming encourages you to sweep state management under the rug, and it usually comes back and causes problems. The point of the functional approach is that it forces the programmer to deal with issues of state management explicitly, so they are dealt with properly.
What FRP does is to give you A way (but not necessarily the best way for all situations) to structure this functional state management. It does this by - instead of separating logic and state - putting them
together at a fine granularity, but unlike imperative programming - in a composable way. These components are composed into progressively more complex constructions. FRP has many of the advantages of the imperative approach, but with most of the disadvantages removed.
I think it's unfortunate not to be able to use FRP with Elm, because it fits the Elm model really well and would be a powerful way to write Elm applications. But there is no reason why FRP needs to be
baked into Elm as it was. The best approach would be to write an FRP library for Elm.
Steve
