So you would say the same for programming in general then? Should programmers not use the word "function" because that word is foreign to non-programmers and might push them away?
For example: I might explain the programming concept of a function as "like the equations you remember from math class" (for pure functions) or "like a recipe" (for imperative functions).
I would also not, for example, make up a totally new term for a concept people already know about that just happens to be in the context of my new system of ideas. This actually comes up a lot in my day to day software engineering work: I avoid creating new abstractions in general, and when I do I strongly avoid introducing new terminology in the naming, and when I do I document and explain it to death in the comments, using analogies wherever possible.
There are lots of opportunities where I could come up with a whole new concept with a beautiful new name that nobody understands, and I explicitly choose not to.
Does what I write above bother you at all? Do you feel that it apply to you and programmers in general? Because that is the kind of generalization you are doing to another group of programmers.
I see a lot of functional programmers spending a lot of time trying to teach others. I also see a lot of people not wanting to spend any time learning so they just talk down on functional programmers, and I think its unnecessary.
I'll admit my emotions got a little heated. I get really frustrated thinking about all the potential out there that gets wasted just because of gaps in communication (willful or otherwise), and not because of capacity for understanding. And this very comments section demonstrates the unwillingness by at least some members of the FP community to put things into terms that would help with that problem, so I do feel justified talking about the community as having an issue. Whether they represent a majority or a vocal minority is not something I can say with confidence, though I still feel like I qualified my original statements sufficiently.
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.
> 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
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.