Along with @HeinrichApfelmus and @mitchellwrosen, I’m happy to announce the release of Reactive Banana 220.127.116.11. Reactive Banana is a library for functional reactive programming. This release is mostly a maintenance one, though there a few new goodies. See the changelog for more details!
I’m happy to see this gem of a library get some love.
If you have ever been curious about what it’s like to write a program using FRP, reactive-banana is the preeminent interface - in any language - to get started.
You just sparked my curiosity. Until now I was lazy to look into FRP more deeply. Could you please give me few examples what are great applications that are made easier by using FRP compared to some other approach?
Is it mostly used for GUI programming or are there other domains where it shines?
Sure. Yes GUI programming, but also games, simulations, reactive or event-sourced applications… basically, anything loosely involving a possibly-dynamic collection of locally-stateful “entities” that relate to one another, whose implementation might otherwise involve spooky callbacks or other non-compositional abstractions.
And as we all know, or at least suspect, non-compositional programs are doomed to collapse under the weight of their own complexity when they reach a certain size (which, for me anyway, seems to have shrunk to a mere 500loc or so).
I only know of Ivan Perez programming real games with FRP («real games» as opposed to «toy examples») and he apparently loves it.
It is a pity because there seems to be much to be gained but most likely not enough info or tutoring to get people committing to FRP.
This comment has me intrigued. I’ve looked into FRP in Haskell, but it’s always been using Reflex. Can someone comment on how Reflex and Reactive Banana compare to each other as implementations of FRP? I’ve found some answers to this, but they mainly focus on Reflex being a more complete implementation, implementing more combinators, more type class instances, more library integrations, and the Dynamic abstraction. This is all in favor of Reflex. I’d particularly like to here about what specific things people prefer about Reactive Banana.
I think your understanding matches mine. Reflex seems like a more mature implementation with many more person-hours invested in optimizations to power larger-scale production web apps.
But note I said reactive-banana offers the preeminent interface, not implementation (though its implementation is neat). Its API is clean, concise, and presents the two core FRP abstractions, Event and Behavior, with about as little incidental complexity as possible. Leak-free higher-order FRP is supported with minimal additional machinery.
In summary, reactive-banana is a great way to get comfortable with the essence of FRP. Maybe I wouldn’t board an aircraft powered by bananas and barbed wire (ok, now I’m mixing metaphors).
By the way, Dynamic is just a pair of Behavior with an Event that is known to be the source of its “changes” (in air quotes, because a Behavior whose underlying Event that emits a value “equal” to its previous, for example, would not be noticeable in the semantics of the Behavior). It’s easy to build and use this abstraction with reactive-banana’s API, if you’d like.
Okay, I understand you. I definitely agree that the combinator names in reflex are sometimes bewildering. Why would you call it
ffilter instead of
filterEvent or something obvious like that, for instance? But completeness of the API, and especially working with a lot of standard type classes, are also very nice things about the quality of the API.
Yes, I understand about
Dynamic, but in the end it’s just a phenomenally useful and simplifying combination of
Behavior, so it’s nice to have it around and have combinators that work well with it! My personal opinion is that, despite the trivial implementation,
Dynamic as a concept is one of the great success stories of the reflex API.