unfortunately this kind of attitude is the root cause of the immediate emotional push back that FP t...

# arrow

[ivanmorgillo]

unfortunately this kind of attitude is the root cause of the immediate emotional push back that FP triggers in most of the developers.
it's not a technical problem. It's an emotional problem.
the moment you make people feel stupid, it's over, you lost them and they will never forget.

if you want to spread a mindset or a technology you have to make it accessible and
accessible means also provide people with example that they can use tomorrow in their code base.

I'm all about improving and growth mindset, but what @Satyam Agarwal said about sneaking Arrow in the code base will never work in most of the companies.
99.99% of them would just stop the PR from merging, because using Arrow is not your decision, but it's a team decision.
what Arrow lacks at the moment is an effective and joyful way of showing how things improve with it.

I have been talking about Arrow around the world for more that a year and people liked my talk because
I give them examples, I give them tiny bits of discussion opportunities.

I talk for an hour about Option, Either, Nel and Try and I never say "monad",
because I know from experience that the moment I say "monad" or "effect" or "applicative" or "bifunctor" or "whatever fancy FP jargon word" I lose the audience.

We need to make it easier if we want to spread it, and even if I can't understand how to use it, how can I ever start explaining to a junior dev!?

[raulraja]

we are attempting to eliminate all type classes

[raulraja]

with just abstracct top level functions

[raulraja]

then you don’t need to mention any abstraction since the abstraction is the method

[raulraja]

inline abstract fun <A> A.combine(other: A): A

[raulraja]

then now types provide evidence of implementation with a single function as member or extension

[raulraja]

and functions are specialized at compile time to the concrete type so they are abstract inlined templates

[raulraja]

that is faster than any abstraction through interface virtual dispatch or type classes

[raulraja]

and it requires no implicit dependencies on interfaces like Monad or Functor

[raulraja]

but it would require meta as compiler plugin

[pakoito]

how can I ever start explaining to a junior dev!?

funny enough, junior devs are more malleable than medior ones. If they start with FP or procedural programming, this feels equally natural to OOP depending of what they’re taught afterwards

[pakoito]

anecdotal evidence anyway but yeah

[tmg]

Also, depends where you are located, for example my local university has FP as the first programming class, and in haskel, sure it only touches briefly on the monad subject there, but it already shows nice things like ADTs, High-level functions, partial application, type classes and all other niceties.

[tmg]

in such environment, i also agree that is easier to persuade a junior, in fact i would even call it trivial, as most that leave such universities, simply don’t have oportunities to work with FP, rather than not wanting.

[aballano]

@ivanmorgillo I partially agree with what you say, we should focus on specific real-case wins or advantages that you gain with Arrow so people can easily understand the benefits.

That said, sometimes is difficult or doesn’t make sense to use different terms for something just because someone doesn’t know the meaning, the same way you wouldn’t change the name of MVI because of the same reasons.

On wednesday we had a Kotlin London meetup where my colleague Dani and I were giving some talks. Mine was related to Arrow and how to refactor an existing app to slightly introduce it without big breaking changes (and without saying Monad 😄 in all the talk), showcasing the wins, if you would watch it and have any feedback I’m all 👂 🙂

https://t.co/47Sfp1LQTA