the thing is, if you have a function

foo :: a -> State s a

it doesn't really return the state itself, because the state we're dealing with is of type

s

. It really returns a deferred computation that returns a state when it's run later on. That's why I think

State

is a wrong/confusing name.

how likely is kotlin going to have typeclass?

we (Arrow team) are working on it, KEEP-87 https://github.com/Kotlin/KEEP/pull/87

Is a long process

Didn't know we had this channel.

Welcome @yaakov!

It’s really interesting to see the perception that most people have of “explaining” FP

Most of them don’t realize they are explaining with the assumption that their audience already understands what they are trying to explain

“Here is the definition of a functor:

(a -> b) -> f a -> f b

. What exactly don’t you understand, the endofunctor or the monoid part?” “Er... What do the arrows mean?”

I know Ken from the Scala and Haskell communities. I think people that follow him are already there but have trouble explaining the relation of those concepts and those tweets are targeted to that audience but I get your point. It's hard though to go back to basics each time you want to explain an advanced concept. I think most FP devs assume others listening are already passed the basics. FP requires a ramp up time beyond just practice to understand the concepts and relationships expressed in the FP type classes like Functor, Monad, etc. When people refer to those as containers or computational contexts to fit them in how they understand programming I think they are missing the point. The importance is the composition and how you go from A to B. You then can immediately identify the abstraction that takes you from a shape to another. For example: I know exactly what it takes in abstractions to go from a

List<Deferred<A>>

to a

Deferred<List<A>>

meaning gathering parallel results from independent computations as they complete in a reactive way. And that is :

results.traverse(::identity, Deferred.applicative())

My point is that I know that because I took time to understand what they are talking about and the relationships you learn when going deeper in Typed FP. I'm not sure there is a solution in FP at that level to be friendly to beginners in the same way is hard in other sciences to explain certain concepts to people that are not acquainted with the topic. So I'd like to advice those just getting started with FP to be patient and don't wait for others to make it easy, it's worth it to learn the terms and concepts that are already in use, and yes still room for a lot of improvement but new concepts and ways of doing things don't come without friction.

And sorry for the rant 😞

The first answer to “Please explain how XXX works” should be “To whom?“.

I want a FP for Dummies article...I find the Functor/Monad terminology confusing 😁

Understanding monads is easy, the hard part is the required PhD in PLT you need

A great port @aballano did for Kotlin of a popular article in the series of explaining these concepts from scratch

For what is worth the grammar of FP sounds scarier but it's a lot less terms than the OOP one, specially when you get to Design Patterns

Grammar is pretty irrelevant to assess the complexity of a topic, whether it be a natural or programming language, But FP is pretty intimidating and redundant in many areas too, e.g. pure, lift, return, point, etc…

that's what they call the methods in different langs, unfortunately everyone thinks the way they name things is the best one. I agree disagreement in those names suck.

Ironically, I forgot the most iconic version of these names:

bind

🙂

I find

bind

a better name than

flatMap

because

flatMap

does not convey that is binding two computations and

flatMap

seems more collection oriented than generalized for all data types capable of providing a monad instance.

Personal peeve: I’ve always found the necessity to flatMap a blemish on the whole concept. “So you can compose these operations like this and blam! magic” “But now I got a

F[F[_]]

, what happened?” “Oh yeah, now you need to

flatMap

to clean up that mess” “And this is better than chaining naked values… how?”

With naked values you don't have composition when sequencing over the effect that been chained by multiple calls to flatMap. Is not clear either how you deffer evaluation. I think

bind/yields

is present just for async computation in coroutines with

async/await

. The equivalent thing here is that how would you implement async/await with naked values? Each monad has a different complexity in relation to the effect they model in this case Async. Other monads model absence, N effects. When all those effects are implemented with naked values they all are implemented in a different way and requires concrete implementations which may be desirable or not based on optimizations. There is room for mutability in pragmatic FP. But I think the idea here is that FP offers a unified programming model for everything where you can express those high level concerns of computing over Effects in the same way for all monads.

Using functional methods in collections is just the tip of the iceberg of what those actually mean and can do generalized to all types that can support them. There is value in that. Learning to solve problems in a unified way instead of ad-hoc each time.

That is to me where names become a bit irrelevant because you focus in identifying the functions that take you from one type to another regardless of the shape they are in. Once you have visited a shape for example going from

F<A> -> F<B>

you know that is

Functor#map

and it works for all data types not just List.

Anyone coming to Kotlin from other FP langs can take Arrow and learn the Kotlin syntax and they know how to use the lib with minor ramp up. So FP brings programming portability of concepts to different langs and I think that is a great skill for people practicing FP. If we rename things we break that property.

That’s not unique to FP though, OOP is in the same boat

Inheritance, overriding, abstract functions, delegation, interfaces, default methods, all of that applies to traditional OOP languages and can be readily reused on your first day in Kotlin

And of course, parametric polymorphism, which transcends both OOP and FP