How would you explain the benefit of the Monadic interface when implemented for Reactive structures to someone unfamiliar with Monads?

[ken-okabe]

I just wonder what is the advantage of having a reactive structure as monads rather than functors.
For list or option, it's relatively well-known how good it is to have monads rather than functors.
Can anyone explain this with a simple example? Thanks.

[Avaq]

Based on your elaboration, I think your question could be rephrased as: How would you explain the benefit of the Monadic interface when implemented for Reactive structures to someone unfamiliar with Monads? Is that right? If so, could you update the question title as well? I'll post a new answer.

[ken-okabe]

Based on your elaboration, I think your question could be rephrased as: How would you explain the benefit of the Monadic interface when implemented for Reactive structures to someone unfamiliar with Monads? Is that right? If so, could you update the question title as well? I'll post a new answer.

I am familiar with Monads and am able to implement a Monadic interface for a Reactive structure on my own, however, I am still uncertain of the benefits. Nevertheless, I have updated the question title as the answer should remain the same. Thank you.

[Avaq]

What are monads?

The Monadic interface is one of several "algebraic" interfaces inspired by "category theory".

Category theory is simply said a theory of theories: It is used to categorize other mathematical theories, and itself. Just as category theory is a theory of theories, the programming interfaces inspired by it are abstractions of abstraction.

Each of these interfaces categorize a common abstraction in programming. For example, the Monoid interface is the generalization of binary operators that combine two values in a specific way. The plus operator is a Monoid for number, the .concat method is a Monoid for Array, and there are many more things that can be categorized as Monoids.

With our Monoid example in mind, let's examine what the Monad interface is a categorization of. It's a little bit more abstract: It's basically the generalization of any operation that depends on the result of a previous, similar operation. So any time we go: "Do one thing, and depending on how that turns out, do another thing", we're doing something Monadic.

We can now make the mental jump to Promises, which are a typical example of a Monadic abstraction. Their whole interface (.then) is modelled to let a user do one thing, and then do something with the result of that. But there are many other things that could be categorized as Monadic, even for example imperative programming languages themselves. The Monadic interface is extremely broadly applicable!

Why make monads?

So why would we go through the trouble of making our abstractions that could be Monadic, actually conform to a common Monadic interface such as the one specified in Fantasy Land?

The primary advantages from my perspective are:

• Reduced mental overhead and cost of learning an abstraction, and
• interoperability with other code.

When all Monadic abstractions conform to a common monadic interface, then learning them becomes real easy! You just need to learn the monadic interface once, and suddenly you can use anything and everything that has "do one thing, and then use its result" at its core: Asynchronous things, optional things, streamed data, parsing, state! The list goes on. Furthermore, because this interface is so strictly defined, it doesn't require much thought to work with it. We know exactly what to expect from a Monad.

Finally, it's now trivial to write very abstract code that doesn't just work on Promises, or just work on Streams, but works on all Monadic abstractions! For example, I can write the following function:

const andThen = (firstMonad, secondMonad) => firstMonad.chain(() => secondMonad);

And instantly I have a function that sequences two operations neatly after one another. It works with Promises, in which case the first async thing happens, and when it's done, the second one happens. But it works also with Optional values, in which case if the first thing doesn't happen, the second one also won't.

This ability to abstract over so many abstractions at once goes much further too. We can create (and have created) general utilities for combining multiple Monads into one, in a fully automated way. Where I can just do OptionalPromise = OptionT(Promise) or something to create Promises that optionally execute. The possibilities are endless!

I hope this convinces you to try and conform your abstractions to the Monadic interface, and/or some of the many other algebraic interfaces.