I am enjoying these articles. However, I think it doesn't quite motivate why I would want to use a monad.
Clearly, it gives me composition, but how often is a javascript program solely made up of transformations like map? Moreover if I have multiple steps of transformation, why would I run it as multiple steps rather than composing the steps into one function and running that? Clearly, some steps can't be combined if they're dependent on async data. Promise is a bit of an anemic monad but for the purposes of typescript it is typesafe, has convenient syntax, and is nearly a no cost abstraction.
Let say I rewrite an arbitrary program in this style, if I had a non-monadic type safe program before refactoring and a type safe program after, what do I really gain for bringing in this abstraction? The two programs should be isomorphic in essence.
I feel like it replaces a sequences of statements with a sequence of expressions. The type signature of chain and flatMap result in examples which are very linear, this item is processed after that, but often I need to deal with branching. One effect kicks off many effects which may have unrelated concerns, how does composition improve this situation?
Another article does a really good job of motivating the effect applicative. jrsinclair.com/articles/2018/how-t... It helps me see why I would want to use the effect applicative in JS/TS. It adds a useful feature to a program, i.e. laziness, but what does or what could a monadic interface bring to a program? I know half the answer here is composition, but what can composition bring to a program that it didn't have before? Another way to put it is that the only usefulness of monads seems proportional to the how much you use composition.
It was a bit meandering but this was a question asking if is it worth it to refactor an imperative style program into a functional monadic style program.
I would appreciate feedback. I'm on the fence regarding this. Has anyone done so? What was the experience like and how was the outcome?
Since no one has answered, I guess I'll answer my own question. Monads, the concept, don't really add anything to a program per se. It is the particular instances of monads themselves which add value. The monadic pattern allows you to compose many instances of monads which add features. Thus the only value in the monadic pattern is acting as the glue with which to compose all the separate features.
Monads are the plumbing which deliver value from the things they are connecting.
I am enjoying these articles. However, I think it doesn't quite motivate why I would want to use a monad.
Clearly, it gives me composition, but how often is a javascript program solely made up of transformations like map? Moreover if I have multiple steps of transformation, why would I run it as multiple steps rather than composing the steps into one function and running that? Clearly, some steps can't be combined if they're dependent on async data. Promise is a bit of an anemic monad but for the purposes of typescript it is typesafe, has convenient syntax, and is nearly a no cost abstraction.
Let say I rewrite an arbitrary program in this style, if I had a non-monadic type safe program before refactoring and a type safe program after, what do I really gain for bringing in this abstraction? The two programs should be isomorphic in essence.
I feel like it replaces a sequences of statements with a sequence of expressions. The type signature of chain and flatMap result in examples which are very linear, this item is processed after that, but often I need to deal with branching. One effect kicks off many effects which may have unrelated concerns, how does composition improve this situation?
Another article does a really good job of motivating the effect applicative. jrsinclair.com/articles/2018/how-t... It helps me see why I would want to use the effect applicative in JS/TS. It adds a useful feature to a program, i.e. laziness, but what does or what could a monadic interface bring to a program? I know half the answer here is composition, but what can composition bring to a program that it didn't have before? Another way to put it is that the only usefulness of monads seems proportional to the how much you use composition.
It was a bit meandering but this was a question asking if is it worth it to refactor an imperative style program into a functional monadic style program.
I would appreciate feedback. I'm on the fence regarding this. Has anyone done so? What was the experience like and how was the outcome?
Since no one has answered, I guess I'll answer my own question. Monads, the concept, don't really add anything to a program per se. It is the particular instances of monads themselves which add value. The monadic pattern allows you to compose many instances of monads which add features. Thus the only value in the monadic pattern is acting as the glue with which to compose all the separate features.
Monads are the plumbing which deliver value from the things they are connecting.
I recommend this talk youtube.com/watch?v=Nrp_LZ-XGsY