Api naming design choices

[thegreymatter]

quick question that intrigues me regarding the design choices behind naming in ibis.
I'm trying to understand the choice behind some of the naming conventions. i.e. choosing "mutate" rather than "with_columns" or "remove_columns" which are more popular in spark and plyr.

as well, in which scenarios do you choose to alias an expression? (for example to my understanding "select" is an alias of "projection" ).

the reason I'm asking, as I'm working on onboarding ibis to my team, I'm trying to leverage familiarity with existing libraries to allow easier onboarding. and usually when there is a mismatch it might mean -

1. there is a good reason for that, which will be interesting to understand.
2. there is a potential to increase usability.

[jcmkk3]

I don't have the backstory, but mutate is also used in the dplyr library, which is very popular in R. I think that most of the aliased methods are done for evolving the API in a backwards compatible way. From what I can tell, select is the preferred method.

[cpcloud]

@jcmkk3 is correct here.

Most if not all of the aliases exist for either 1) backwards compatibility or 2) convenience.

As far as the choice of new names or new aliases we don't have a strict algorithm that we go by, but there are roughly three main places that we look to for inspiration:

1. Python APIs. Ibis is first and foremost a Python library, so we try to make many of our APIs familiar to Python users regardless of what their starting point is. Slice syntax for array columns and string columns as well as using zero-based indexing regardless of the backend are both example of Python-inspired APIs.
2. Pandas or dplyr APIs. Both of these ecosystems are heavy influences on ibis and we take from them where we can. mutate is a good example of sourcing from dplyr, mean is a good example from pandas.
3. SQL functions. Ibis is designed to make interaction with SQL much easier than other libraries and so we inevitably take at least some API naming choices from SQL. Many of the names of functions are just taken directly from one or more SQL dialects. StringValue.substr is a good example of this.

[cpcloud]

We are generally -1 on having many ways to express the same thing, with different APIs and (roughtly speaking) -0.5 on having many aliases (different name, same exact API) around to avoid the confusion that comes from optionality, e.g., tab completing and seeing a bunch of similar things and having to look at each one to whether they are different from your mental model.

[cpcloud]

Thanks for the discussion! Hopefully it's more clear why things are the way they are.