3 ms·
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
by mattgreenrocks 13y ago
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.
- steveklabnik 13y agoYup! 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. 1: https://github.com/steveklabnik/frappuccino https://github.com/steveklabnik/frappuccino
- mattgreenrocks 13y agoFRP 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.
- seanmcdirmid 13y agoExactly! 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. [1] http://research.microsoft.com/pubs/211297/managedtime.pdf http://research.microsoft.com/pubs/211297/managedtime.pdf
- mattgreenrocks 13y agoI love this. I have a feeling we'll see something like this in production one day. How'd you get hooked up with MS doing such cool stuff?
- seanmcdirmid 13y agoActually, MSR is supposed to do cool stuff. I got here by accident, mostly.
- pseudonom- 13y agoMy understanding is that there's a fundamental trade-off between expressivity and efficiency (while maintaining referential transparency): https://blogs.janestreet.com/breaking-down-frp/ https://blogs.janestreet.com/breaking-down-frp/ http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13.html http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13... http://www.testblogpleaseignore.com/wp-content/uploads/2012/04/thesis.pdf http://www.testblogpleaseignore.com/wp-content/uploads/2012/...