[Phaedor]

I am a self taught programmer who first learned python and then learned Haskell. A lot of concepts in python were difficult when I was new and the same is true for Haskell. I found the Haskell community to be very welcoming and very willing to explain their terms and the reasoning behind them, and I dont find the negative characterizing from you and others about them to be true at all. That's why it really bothers me how you and others are so willing to slander a whole community based on what I perceive as not the truth at all. That's also why I wonder if you would be ok with non-programmers making the same generalization about programmers.

In my experience concepts like Functors, Monoids, Monads etc. are difficult, not because they are complicated, but because they are seemingly too simple. A Functor is pretty much something you can map, and every programmer knows list.map, so what's the point? The point is that when you have some infrastructure around using them, then you can see new ways of using them, and you can see that mapping makes sense over a lot more structures than lists. Even over something like a function "a -> b". The problem is that non-functional languages doesn't have this infrastructure around them, so they are not very useful, and so its difficult for people not using functional languages to understand what the point is. I dont really think there is any way to get past this unfortunately and the only way to get comfortable with the terms is to program in a functional language.

[momentoftop]

Good points. But I'd note that Haskell's infrastructure around Functor isn't typical of functional languages. Specifically in Haskell, I think it's pretty important to have an idea what functors, monoids and monads are, because these are typeclasses that you will almost certainly be using at some point. Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly.

[Twisol]

I agree with your overall point, but I want to dig in on this bit:

> Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly.

This is true only in an especially strict sense. Haskell's typeclasses provide two basic mechanisms: one for associating a dictionary of data with a type, and one for automatically picking / deducing such a dictionary based on a given type. Only the latter is specific to Haskell (and Scala); the first can be performed even in Java, but you have to explicitly pass the desired dictionary (called a "trait") at all call sites. [0]

I legitimately use traits all the time in Java, and it even has some built-in ones, like Comparator. There's a great paper on the same fundamental technique at [1] (there called "object algebras").

[0] https://www.haskellforall.com/2012/05/scrap-your-type-classe...

[1] https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf

[momentoftop]

It's certainly possible to express some of these ideas in other languages, but implementations are nowhere near as ubiquitous or idiomatic as in Haskell, where they pervade the standard library and most people's code. And I'd argue that's because the ergonomics of the solutions in other languages don't come close to those of Haskell's. Furthermore, there appear to be limits to how far you can take them.

For example, Java lacks higher-kinding which is needed to define a monad abstractly. This can be got cheated around using ideas from this paper (0), but it costs a cast which the compiler cannot prove safe. This is the basis for things like the arrow library in Kotlin, which while impressive, doesn't compare to the ergonomics of Haskell and still misses a bunch of standard abstractions such as Traversable, which are part of the mentioned infrastructure that makes monads (1) so useful to Haskellers.

[0] https://ocamllabs.io/higher/lightweight-higher-kinded-polymo...

[1] applicative functors more generally.