not because it’s the practical thing to do, but be...

# arrow

[kyleg]

not because it’s the practical thing to do, but because it gives me a reason to learn more about FP

[Jannis]

A monad-transformer based architecture is very practical, just not in kotlin. There is currently a rework for IO in progress which turns IO<A> into IO<E, A> which makes the failure conditions of your IO explicit. This means you can easily predict and handle how IO will fail and you can even define IO<Nothing, A> as an IO that should never fail. (It still can but IO<Nothing, A> denotes unexpected failure. The mtl pattern for this is EitherT<ForIO, E, A> == IO<Either<E, A>> , but the inbuilt one is much easier to use.
The next step is adding IO<R, E, A> which adds a context to your IO . This means you will have read access to context from within IO . The mtl pattern for this is Kleisli<ForIO, R, A> == (R) -> IO<A> == ReaderT<ForIO, R, A> , but again in-built it's much nicer. This basically replaces the need for DI.
It is still very valuable to learn how to use the specific monads tho, just a sneak peak on how arrow will make this practical even in kotlin 😅

[jimn]

are the kotlin shortcomings related solely to operator inflexibility to match haskell and scala on 1:1 ?

[Jannis]

Nope, it's because of wrapping and unwrapping and method scope. I am talking about monad-transformer-stacks: Haskell can look up all methods and types easily whereas in kotlin you have to do that all manually, sometimes even types

[kyleg]

Just a nota bene, by “practical” here I mean “for me personally at my knowledge level.” I can crank out semi-FP, mostly imperative code and be done. Forcing myself to use State, Reader, etc. will slow down my development for one-off hobby projects. I recognize that it’s highly practical if you’re a certain level of expertise with certain toolsets. 🙂

[kyleg]

I don’t speak Haskell and 95% of tutorials on how FP works are in Haskell, which I find legitimately very difficult to parse.