However the usual industry terms for these are map, filter, and reduce.

I do not know whether these are "industry terms" per se, but I think that

the map/collect alias example was once explained in that matz wanted to

make it easier for people who are using other languages, to use ruby

"out of the box" in a way that is more similar to how they think (and

thus write and design code). Of course they can also modify ruby as-is

and add the aliases on their own, which would also include filter, but

in many ways I think that I agree with you that filter is used in other

languages too, and since it is not yet used by ruby by default, it could

find a use there. So I have no objection.

There is however had only one smaller issue - I think in terms of .select

and .reject already as filters. They just do the opposite of each other

in their selections - one does a positive "give me the matches" and the

other the "give me the non-matches", or "reject the matches", which can

already be inverted via '!' for example.

So I am slightly +1 on the suggestion, but the docs should explain why

.filter is used as alias for .select but not .reject if this is added.

I guess the ruby core team may discuss this - ultimately matz has to think

about it if it fits or does not fit or is similar to the reason for

map/collect addition many years ago (I do not even know which ruby

version had it... when I started to use ruby, map/collect was always

there and I always used only .map and never .collect; and I guess there

are people who are doing this in the other way too. More than one way

to do something). :)