The mathematical terminology that you dislike has already been well established and well defined after decades of use in many formal publications. It will probably be continued to be used for hundreds of years. In no way is "Enterprise Java Beans" analogous.
I'm actually indifferent to the terminology, having used my fair share of Haskell/ML/Lisp, but I can see how you came to that assumption.
> in many formal publications
I'm aware of this, but the thing with this is not everyone in software has a computer science background, let alone an academic background. I'm a freelancer at the moment, but if I used most of this terminology in my workplace people would be giving me wtf looks.
> In no way is "Enterprise Java Beans" analogous
How so? All I said formal names in mathematic/computer science, give next to intuition into their actual meaning & when you look up their meaning, most of the results are riddled with more terminology. Same kind of goes for a lot of the Jagon in Java enterprise stuff, like beans/services/factories/etc. I wasn't saying their exactly the same, but more I had a similar experience when trying to familiarise myself with that stuff.
The danger of "intuitive" names and analogies is that they often don't capture the generality of the abstraction and can limit ones thinking. The mathematical terms are useful and communicate precisely and unambiguously (e.g. if someone says X is a Functor then I assume the Functor laws are satisfied). Ignoring established terminology creates insular communities and creates confusion (e.g. a C++ Functor versus a mathematical Functor, C void versus type theory void). I agree that better books and learning resources are needed, but changing names is anti-intellectualism, IMHO.
> I agree that better books and learning resources are needed, but changing names is anti-intellectualism, IMHO
To clarify I'm not suggesting changing existing names in mathematics or existing APIs, I'm just suggesting in documentation / blog posts / educational stuff we should avoid using the more intimidating terminology if a simpler term convoys the message better, especially if the terminology gets in the way of educational material doing it's intended purpose.
Maybe this wouldn't be a problem if mathematic education content was more accessible, I don't know but at the moment I really don't think it is. Like it would nice to have a nice accessible book like "Category Theory in Python/JS" or something to refer people to... But I agree, changing names is anti-intellectualism
> The danger of "intuitive" names and analogies is that they often don't capture the generality of the abstraction and can limit ones thinking
I get that, & I feel in mathematics that is important, but in writing an API having slightly dishonest names is okay. Like a name like `flatMappable` vs' `Monad` even though not all Monad's work like a flatMap, but I get what you're saying new users might think monads are just a collections API thing, but maybe if they saw it on an Optional/Error/Promise/Async/etc this wouldn't be a problem, I don't know. Maybe it's a matter of establishing a culture where the use of these names like flatMap are first demonstrated with none collection types, again I don't know. I'm really just throwing ideas out there, but I feel it's something to consider.
