While I appreciate FP using terminology from its math origins - I do think it's a huge barrier for entry, and not really sure languages that cling onto them, will see much real mainstream success.
But then again, I don't think the language maintainers et. al. are too concerned with widespread success. Just some observations, but the majority of people I know that actively use FP languages, are academics. I've encountered some companies that have actively gone with a FP language for their main one - but some have reverted, I guess due to the difficulty of hiring.
With that said - functional elements are becoming more common in widespread languages, but not all the way.
I think using math terminology is honest, in that it gives an accurate expectation of how the ideas can be communicated and learned. They are simple ideas that can be communicated in their entirety in just a few symbols, but it takes time, exposure, and practice to develop facility in their use and a feeling of "understanding."
That's the math experience. I know people hate that and would much rather it be a matter of reading some a nice explanation and then "aha" but there's no such explanation yet and after years of people trying to develop one there's no point in expecting one right around the corner.
I agree about the math terminology, but I think it would be more confusing if we created a completely different set of vocabulary for the same concepts. So I don't really know what to do: refer to something by its proper name, or create a new, less precise name to make it sound less scary? Why do we find certain identifiers scary in the first place?
I don't. FP terminology is so bad that clearer names (Mappable, Chainable, etc.) would really help adoption.
You might say "but it will make it more confusing for people who already know the FP terms", but those people are a tiny minority of programmers so it doesn't make sense to cater to them. At least if you want your language to be popular among anyone except academics.
> You might say "but it will make it more confusing for people who already know the FP terms"
People who already know FP would be fine. Newcomers would be the ones to suffer. We already have a large number of tutorials, blogs, books, etc. using the existing terminology. For a programmer new to FP to tap into that they would need to learn both the "friendlier" (whatever that means) terms as well as how they map to the math terms.
We need to stop treating math like some unlearnable alien language—you'd still need to learn it anyway, regardless of what you call the abstractions. Also in many (perhaps most) cases there is no clear choice for the "friendly" term. Words like "chainable" would be highly ambiguous, as many different types of abstractions support some notion of "chaining". This would likely result in bikeshedding and more divergence in terminology and less precision in meaning.
If you think the math terms are bad, try asking a mathematician to rename the terms in their field. They'll tell you the same thing.
A "functional language", like an "object-oriented language", is an exercise in futility. But support for a functional approach in a general language will often be useful.
But then again, I don't think the language maintainers et. al. are too concerned with widespread success. Just some observations, but the majority of people I know that actively use FP languages, are academics. I've encountered some companies that have actively gone with a FP language for their main one - but some have reverted, I guess due to the difficulty of hiring.
With that said - functional elements are becoming more common in widespread languages, but not all the way.