I think FRP is a good idea; but it seems to expose a failing of many languages: the lack of metaprogrammability. In particular, most (non-Lisp) languages don't let you mess with control flow much.
The result is that when writing FRP code, users have to manage two control flows: the 'logical' control flow, which is expressed via whatever FRP library they're using, and the actual control flow, which is the one provided by the language they're in. Languages would need good support for source-to-source transformation, or, alternatively, allow the compiler IR to be manipulated by libraries.
From the little I've played with Haskell, it appears the monadic binding operator (>>=) lets you do this, and the user writes code in an idiomatic, imperative-like manner. It is extremely impressive that this capability can be used to arbitrarily extend the language, while being a very small concept.
Edit: not sure if I had my terms right on the operator.
Exactly! This is why I've turned my research away from FRP-style lifted values to just lifting all the code over time [1], so control flow is quite normal.
Yup! I would agree with this too. I've actually written an FRP library in Ruby[1] and it's not really _useful_ yet because of these kinds of issues. I was thinking about how I'd use it to build a web framework, for example, and I'm not sure it's a significant improvement.
Regarding >>=: yes, it's the 'bind' operator, and yes, it is really impressive. This is why monads are hard: they're so abstract that they're good for _many_ things. It's also why they're so great.
FRP strikes me as much, much closer to how Things Should Be(tm), but it still feels off somehow. Perhaps it's just too low-level. It should really part of a language's runtime, rather than exposed to the user. Right now, most FRP implementations kind of take over your system: you're always sweating whether this is a special reactive type vs your domain type. Even C#'s async/await (not quite the same thing as FRP) seems to have a similar effect, where the async function keyword propagates through your codebase quickly (caller/callee have to agree on this I believe).
FRP still feels like it's in the early stages, so I'm confident someone will find a better way to apply it. Right now it seems more palatable to non-bleeding-edge devs if you tailor it for specific use cases, rather than the whole thing at once. It may be the concept is too big to sell right now.
Are you referring to the various databinding frameworks? So far, I've been somewhat skeptical of those--I worry they make too many assumptions and take away too much fine-grained control.
The amount of people I know who use functional frameworks (say Underscore) to build things but don't really know much about functional programming is astonishing. To be fair, a lot of frameworks that espouse "functional programming" do so just because it's popular and really push imperative concepts instead so it's easy to be confused on the "right way".
I love Underscore (and Haskell), but I wouldn't consider Underscore an FRP framework at all. It's functional, yes, in the sense that it provides some of the most common FP operations like map, filter, etc, using lambdas. But I don't see the reactive part. Maybe there's some kind of reactive feature tucked away in Underscore's rather large feature set, but I haven't seen it, and it's certainly not core to the library.
We are able to subvert WPF databinding mechanisms to allow bindings to expressions as well as functions. The act of binding itself is still very imperative (and so, not very FRP-ish), but beyond that the programming styles are quite similar.
