> I wish people understood that fp is much easier to understand by reading definitions.

The real landscape of its adoption begs to differ. For the great majority of people, examples and analogies are fantastically more efficient for communicating ideas than building up from first principles. You get to re-use existing mental machinery, intuition, etc, until enough experience has been gained to refine it.

What do you mean?

These concepts are usually explained via first-principles definitions, and they are usually opaque and unapproachable for most people. That's not a coincidence.

There's nothing in this list: - Algebra: Semigroups, Monoids. - Algebraic Data Types: product and sum types. - Functor, Applicative, Monad

which covers basically all the fundamentals to be proficient in functional programming that has definitions that are opaque and unapproachable. And all of those have very simple examples, both in real life and especially programming. But definition has to come first, or you have this great mass of people that do not understand what they talking about even when they blog about it.

If you can take your time to understand that a type constructor (and take the time to see what it is) and a map function form a pair called functor, you are equipped to learn about monads.

It's not rocket science, but yes, it requires a bit of studying and learning, which is what people don't want to hear, and instead choose the long road of contrived example-driven, inaccurate and confusing blog posts.

As another commenter pointed out, the key is to use an example as a starting point and then refine from there. "X is like Y, but different in these ways". Comparisons don't muddy the waters; they give people a quantum-leap from 0% understanding to 70% or 90% understanding, from which point the remaining gap can be filled in at the usual rate. To ignore this is to ignore human nature.

> `a -> b -> f a -> f b`

(a -> b) -> F a -> F b; the parentheses are critical. I don't fully disagree with your point, but if you're going to emphasize rigor and definitions, it would be wise to make sure you're not setting people on the fence up for mistakes akin to those in the original post.

(You also called it `F` and then used it as `f`.)

To add, I suspect that the Haskell type notation is not intuitive to people not familiar with it. For anyone wondering, (a -> b) -> f a -> f b means "A function taking a function from one type to another "(a -> b)" and a functor applied with one type "(f a)" and returns a functor applied with another type "(f b)".

I do think familiarity plays a big role. I find the Haskell syntax much more pleasant than Java, even though I'm perfectly familiar with both.

The equivalent signature in Java (if we could abstract over type functions) would be:

    interface Functor<F<_>> {
      <A, B> Function<F<A>, F<B>> map(Function<A, B> f);
    }

You'll find very similar in Scala's `cats`, up to some currying and reordering. [0]

[0] https://typelevel.org/cats/typeclasses/functor.html

I absolutely agree, I was just adding the explanation for anyone unfamiliar with the syntax.

And I was building on yours :) I hope you didn't mind.

> I wish people understood that fp is much easier to understand by reading definitions.

I wish more FP writers understood that not everyone has the same neurotype, and "easier to understand by reading definitions" is far from a universal statement.