Would you not agree that runA is a pretty obscure name, regardless of whether it's already used in Scala? I think it would be better to use more explicit names. I'm generally wary of names that rely on convention, although its not always feasable to avoid. For example Factory, Visitor and so on are also a convention and relatively meaningless on their own, but at least you can take a good guess. This however, seems like a very clear cut case to me where the API can be made much more friendly at very little cost, not to mention that FP developers shoukd have no problem adopting to simple naming changes when theyre already familoar with the concepts (the reverse is decidedly not true for OOP devs)

I do have a question regarding this: Why can't it be the reverse? Why can't OOP devs can't be to understand the concepts? Where do you place the balance?

The concepts stay the same whether you change the names or not. Most FP devs would probably recognize a State monad even if it were named Foo. But it becomes vastly easier to learn if the names make sense.