[js8]

> IMO naming these programing constructs after their arcane mathematical roots is toxic to the advancement of the field.

I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not.

It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions (too little bang for the buck). (The other two criticisms are lack of formal definition and lack of representation in the computer language.)

[mavelikara]

> I disagree. Why not call a duck a duck, and instead invent your own terminology, just because you're in a different field? Mathematicians invented those concepts first, whether you like it or not.

Mathematicians discovered the existence of these structures first and gave them names. Programers 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.

> It's actually one of my three criticisms of (OOP) design patterns. Often they are just another names for a contrived way of how to pass functions as arguments, so they are actually bad abstractions.

They are not, and have been employed by couple of generations of programmers to create useful software.

[js8]

> 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.

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.

[mavelikara]

> 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.

[js8]

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).