monet/monet.js

[Discussion] Why are you offering so many aliases?

Opened this issue · 3 comments

tho-graf commented

Hi there,
I played a little bit around with monet.js and really like it.

There is only one thing, I think, creates more problems when working with a team on a codebase than it solves. So many different aliases for the same thing. I know, that depending on the library or language, there are different names for it. But at least the one codebase is consistent.

Sure, you can specify some conventions -- but why add conventions if you don't need them.

I would like to hear your opinion on that.

Thanks,
Thomas

ulfryk commented

Good point @thomaskempel :)

If you are thinking about bind / chain / flatMap alises then answer is simple. Name defined by Monad definition is bind and it's used in other libraries for monads, so we need to have it. In FantasyLand it's defined as chain -- monet aims to be fantasy land compliant so we need chain. And last one -> flatMap is probably most commonly used one in many libraries so 3rd alias is needed.

when working with a team on a codebase

So probably each team, on each codebase should decide which convention is most common for their set of libs and depend on code review / linting to ensure that everyone uses the chosen convention.

On the other hand there is Just/Some + None/Nothing - and here I have no answer. Probably in 1.0.0 version there will be only one of them.

  • 👍1
tho-graf commented

Thanks for the insights and your thoughts.

This is just my opinion, but I think that the best solution (for beginners of fp -- there are a lot at the moment, including me -- and even for advanced programmers) would be to have only one API, everything else is just a unnecessary cognitive load (to learn, to use, to read and to teach all aliases), which finally leads to an accidental complexity in our codebases.

The most reasonable API -- for me -- would be to align with the FantasyLand specs, because their goal is to unify.

  • 👍1
shea-parkes commented

Although I agree that one name for each concept would be best, I actually appreciate all the aliases in this case since they accurately reflect the inconsistencies in the broader community.

Ultimately, I'm fine either way; I just wanted to share another perspective. Thanks for the clean library!

  • 👍2