my two cents on the above discussion about naming ...

# arrow

[acando86]

my two cents on the above discussion about naming conventions, also because I'm currently helping to percolate FP concepts to people coming from more imperative background (eg, some android developers more familiar with traditional java style/OOP).
Although i can partially agree that names like Monad, Applicative etc might sound scary for those who come from a different background, i also think that choosing unconventional names like chanable or container is just a palliative to increase the appeal but at the same time it is extremely misleading. IMO we should focus (as programmers in general) to focus more on the concepts behind and try to understand if/when/how/WHY such abstractions and their properties can be helpful when writing code. Although chainability and containers refer to some behaviour we can qualitatively observe when using these concepts, I don't think this captures the essence of these concepts and the power of these abstractions. Although composability is at the heart of lot of concepts borrowed from category theory, terms like Containers or dotchains are quite generic, not precisely defined, they refer more to the way we expect to use things rather than their fundating properties, they shift our focus on a particular aspect of those things instead of driving us to an appreciation of how to reason in terms of these abstractions. It's actually a nice exercise to compare how either the monadic or applicative properties actually constrains us , what they allow us to do and achieve and what not.

[rawtoast]

I agree, even though it can be hard for newcomers — the terminology is transferrable.

[tmg]

they refer more to the way we expect to use things rather than their fundating properties

I think this is the biggest point. Naming something after a use, constricts your thoughts on that particular use.

[tmg]

And just going with math, you avoid a bit the framework/lib naming hell on change.