<@U70MWFK3P> What we noticed is that most (not all...

# arrow

[streetsofboston]

@Miguel Coleto What we noticed is that most (not all) of our mobile (Android) apps we make have very little business logic. That is all on the server. And business logic would be the prime target for coding it in FP.
Most of the code deals with the ‘edge of the world’: UI/Services on top; Network, Cache, File, BLE, etc on the bottom.
There is very little code in the middle: ViewModel and datasources (and some UI validation)

[Miguel Coleto]

Yup, and as an Android developer myself I wouldn't use comonads in a daily job or at least not right now because the boilerplate they introduce does not improve viewmodels

[Miguel Coleto]

But compose can be a real change in the game as it is really similar to React which is very very functional

[Miguel Coleto]

We could transform our UI in pure functions

[streetsofboston]

That is indeed promising. I’m waiting how that plays out.

What we do use, though, from FP, is some data-types, especially the Either<E,T> to force proper modeling of not only the successful types T but the error types E as well.

[simon.vergauwen]

Actually the @compose functions have to be pure but it’s not enforced AFAIK.

[raulraja]

Dealing with effects is the prime target for encoding it with FP

[raulraja]

All those are effects

[raulraja]

It's not just the data models that concerns FP

[raulraja]

But the management of the effects in which an otherwise impure system is delimited inside IO. That is in my opinion as important to FP as the actual domain and type modeling of the data part of a system. Presentation is as much an effect as it is persistence, network, caching or anything you want to track as an effect. That is the main concern of typed FP specially in the context of the JVM where we interface with impure APIs