> Mathematicians discovered the existence of these structures first and gave them names. Programmers also came across them, and there is no shame in giving the structures better names more appropriate to their own field - whether mathematicians like it or not.
Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
Regardless, I think it is a shame to call the same thing differently just for the sake of it.
> They are not, and have been employed by couple of generations of programmers to create useful software.
> Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
Yes, I am aware of it. I have read Wadler's papers pointing out that list comprehensions are a specific instance of a Monad and proposing Monads as a way to structure functional programs. But I wish the Haskell did not directly copy the term Monad into the language, setting off this bad precedent. Like CAR and CDR in Lisp, unfortunately, this one will stay in Haskell. Hopefully future languages will introduce more sensible terminology, like how Lisps have evolved over the years.
> Regardless, I think it is a shame to call the same thing differently just for the sake of it.
We have to agree to diasgree on this. IMO the intended usage of a concept should dictate its name, not how humans first arrived at it.
So what names do you think should be used instead of Monad, Applicative, Functor, .. ? (There was an interesting discussion about this on HN: https://news.ycombinator.com/item?id=9887728)
Funny, I actually prefer CAR and CDR in Lisp to FIRST and SECOND, and I learned it only a few years ago. (It seems to me that it's more poignant since the lists are composed of cons cells.)
I think it ultimately doesn't matter - the usage of the term dictates its meaning as much as the other way around (but this can again be my mathematical background talking, which explicitly tries to unteach you to intuit based on the names of things).
Actually this is not what happened here - when programmers added the concepts you mentioned, they were very much aware of the mathematical counterparts.
Regardless, I think it is a shame to call the same thing differently just for the sake of it.
> They are not, and have been employed by couple of generations of programmers to create useful software.
I can somewhat recommend this presentation: https://www.youtube.com/watch?v=Rmer37g9AZM
The concepts presented are very sound, however the presentation could be a little better.