On: The Essence of FRP [video]

[rubiquity]

Agreed. I bet the author thinks this way solely because Elm is strict rather than lazy. So what? Strict is much, much more simple.

[ericssmith → rubiquity]

No. The author is the originator of FRP and has had a clear definition of it for almost two decades that included a written denotational semantics and modeling of continuous time. FRP has been confusingly redefined by a string of people in the last few years. They could've chosen other labels.

[vvanders → ericssmith]

The thing is elm doesn't say they are FRP, just that they borrow ideas from it.

[ericssmith → vvanders]

http://elm-lang.org/papers/concurrent-frp.pdf

[vvanders → vvanders]

Since I can't reply directly that paper references classical FRP and how elm differs.

Anyway my metapoint still stands in that tone is a poor way to foster community and collaboration.

[rubiquity → vvanders]

Not only that but purist definitions help nothing at all. I don't care if FRP is well defined. If the definition of FRP doesn't make my programming experience better but FRP with some adaptation does, then I'll take the latter every time.

[dang → rubiquity]

You guys are being too dismissive. If the creator of a seminal concept wants to explain precisely what he meant by it, it behooves us to listen.

This thread should be about the substance of what he says in the talk, not perceived slights to other projects which we're all still free to use.

[rubiquity → dang]

I don't take issue with Conal Elliott taking the time to explain what he meant by it. I very much appreciate that! My issue is with the poster above that puts down languages with FRP concepts because they aren't "The FRP, The Whole FRP and Nothing But The FRP."

I love the FP community but if there's one thing everyone on a whole could learn it is that purist beliefs do no good for FP adoption and only help reinforce the "Functional Programmers are condescending" sentiment.