Bikeshed opportunity: filter/map/reduce naming

[Howard Lovatt]

+1 for Sam's reduce -> combine, fold -> reduce
+2 for fold -> reduce only, i.e. simplify API and only have non-homogenous form

 -- Howard. 

Sent from my iPad

On 03/12/2012, at 1:16 PM, Sam Pullara <sam at sampullara.com> wrote:

> Thinking of Hadoop since people are starting to get familiar with that in the Java space:
> 
> current reduce -> combine
> fold -> reduce
> 
> Seems like that matches a little better.
> 
> Sam
> 
> On Dec 2, 2012, at 5:57 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
>> What I'm hearing is: no one seems to have much problem with filter, map, or reduce.  Ain't broke, don't fix.  Going once, going twice...
>> 
>> Next question: what about fold?  What we're now calling reduce is a homogenous (TxT -> T) left-fold.  What should we call the nonhomogeneous (UxT -> U) fold?  Right now we're calling that "fold".
>> 
>> On 12/2/2012 8:30 PM, Raab, Donald wrote:
>>> Let it be said that Doug went to the Green Eggs and Ham before I did.  IIRC GE&H was written with less than 50 words, so Dr. Seuss must have spent a lot of time getting his words just right.
>>> 
>>> I think it is important to have a consistent "set" of names, with a single answer to "Where did that name come from?"  GS Collections borrowed its initial set of collection names from Smalltalk (select, reject, collect, detect, injectInto).  It should be trivial for Smalltalk, Ruby and Groovy developers to understand the protocol.  Not everyone likes the names, but it saves potentially hundreds of hours of debate on individual bikeshed opportunities. ;-)
>>> 
>>> If you choose select, you should probably choose collect.  Reduce is different.  You can achieve reduce with injectInto, but injectInto is more closely related to foldl I believe.  So as Doug says, reduce should just be reduce.
>>> 
>>> What would you like the Java names to be similar to Brian?
>>> 
>>> Filter/Map/Reduce seems to be most similar to Python, Scala / Haskell / Lisp.  I'm fine with any of these naming conventions.  I do feel transform would be a better name for map in Java.  Map is an overloaded term in Java.
>>> 
>>> On the low percentage chance you go with select/collect, developers using GS Collections + Java Streams are going to either be happy or miserable.  I can't tell which for sure.
>>> 
>>>>> (No, Don, we're not going with the Dr. Seuss names. :)
>>>>> 
>>>>> But, people have complained about filter because they can't tell
>>>>> whether we are filtering OUT the elements matching the predicate, or
>>>>> including them.  Some of these people have suggested
>>>>> "where(Predicate)" as an alternative.  Which seems OK to me.
>>>> 
>>>> "select" is the most classic name. Especially for a database company :-
>>>> ) Also "selectAny" etc.
>>>> 
>>>> 
>>>>> Others find "map" too math-y.  (The alternatives I can think of are
>>>>> also math-y; project, transform, apply).
>>>> 
>>>> Do they think that "java.util.Set" is too mathy?
>>>> 
>>>>> 
>>>>> Further, "reduce" and "fold" are unfamiliar to many Java developers.
>>>>> The .NET folks went with "aggregate" to describe their
>>>> reduction/folding operations.
>>>> 
>>>> Stick with "reduce". Nothing else means the same thing with such
>>>> clarity.
>>>> "aggregate" is crummy because it is a noun and verb.
>>>> "fold" is also crummy because it has too many slightly different
>>>> definitions out there.
>>>> 
>>>> -Doug
>