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?
Some terms are used for radically new concepts with no analogue, some terms refer almost exactly to concepts people already know, and some terms refer approximately to concepts people already know (and could be explained as "like X but with these differences")
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.
I actually agree with this much. Explaining monads before explaining a lot of concrete examples of monads is putting the cart before the horse, and is where a lot of these tutorials go wrong (https://m50d.github.io/2013/01/16/generic-contexts is my own effort at taking the opposite approach). But calling something a functor when it isn't is extremely unhelpful; the whole point of using a special-purpose term like functor is to be very precise about what it is and isn't, and to avoid intuitions that would be misleading.
It often makes me very mad that so much gatekeeping has been sown into programming circles through the invention of pointlessly-obfuscated terminology for everything. Programmers are really arrogant most of the time, they dont want to teach beginners their craft so they just make everything difficult on purpose. They are like medieval priests yada yada.
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.
Generalizations are always imperfect, and I felt I was explicit about the fact that there are exceptions (like the OP).
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.
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.
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.
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").
It's tricky with functional programming. It's like reading SICP, and after a lot of effort, y-combinators and stuff, the outcome is like "See? Thanks to this invention, we can easily pass multiple parameters into a function". Which is fun, but not anything that will impress a non-functional programming user.
This is not an unusual thing to see around foundations of mathematics, either - where it could take dozens of pages filled with complicated argument and construction before one eventually can say, “We can multiply these integers now!”
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.