OTOH

• reduce/reduceRight are the names of the native Array methods, consistent with every, some, etc.

My pref is to keep both, but if we gotta remove one I would actually lean to removing fold*, even though that is the one i prefer to use

Consistency with the names of built-in methods is valuable, but less so than internal consistency. If we can have our 🍰 and eat it too, marvellous. If not, let's make Ramda's function names cohesive.

Standardizing on R.every and R.some in #301 was a well-intentioned change, but we failed to consider the cohesion of Ramda's function names as a whole. As a result, we have R.every/R.some and R.allPredicates and R.anyPredicates.

imo if you do this, you should keep reduce in the docs, so that people can find fold when looking for reduce. for the non lispers 😄

@davidchambers I am firmly in favor of 🍰, both having and eating.

i guess it makes sense to do this, esp. now that we have switched to any and all and are not following the language's names. @CrossEye any objections?

/ping @CrossEye

mmmm 🍰

Thought I responded earlier. 🌿

If we're going to get rid of the 👽's let's do it!

i realize i'm too late, but one other thing: should fantasyland add foldable/traversable then they will probably standradize on reduce cf. fantasyland/fantasy-land#7 fantasyland/fantasy-land#68

Missing out on reduce is a real shame, its mentioned in just about every introduction to FP ever 😢

i agree, i think these aliases are worth keeping, esp. if I ever get back to transducer integration.

👍 for reduce/reduceRight

pay no attention to my comments above. 😛

I'm for internal consistency, but I dont see why you can't leave the aliases in there for compatibility. Our company has completely bought in to ramda, and after updating, our code and tests are throwing errors left and right everywhere we used reduce. Why should a philosophical decision that depreciates common aliases break our software (even if the offending principle is sound)?

❓ Where does this come from? I don't mind cleaning up the Ramda api (e.g. all this .idxstuff) but this name change of a core function seems so arbitrary to me. I fear in a future version of Ramda there comes someone else who deprecates fold and re-introduces reduce again. What a nightmare! 😨

I came from a strong JavaScript and C++ background to enjoy doing FP with Ramda v. 0.8 in our latest web project. Using reduce feels quite naturally for me.

Agreeing with @semmel and @jschomay but I also think this change comes a bit fast. Even though ramda is < v 1.0.0 and no contract is broken by this change, it would have been nice with deprecation warnings so that people could adjust instead of running in to a wall of errors when upgrading. Just a thought for the future.

/Captain Hindshight

This was definitely too hasty. The parable was quite convincing. But I'm afraid that we will need to find a way to support aliases. I had said that this was the only alias pair I wanted to keep (#574 (comment)) but that for consistency we should probably remove even this one. I didn't know which one I'd prefer to keep. I think we chose wrong!

But as I think about it again, I really would like for our dynamic dispatching to grow to support more compatible libraries. It would be great to be able to work more closely with tools like Highland, RxJs, Bacon, and possibly promise libraries (less likely as their terminology is quite different), as well as the various immutable collections. In order for that to work, we will probably want to have more, not fewer aliases. (Of course our current dynamic dispatch doesn't work with aliases in any case, so that would have to be straightened out first.)

But I'm all for putting this one back immediately and pushing out 0.9.1 with this and any doc changes done so far.

0.9.1 is already out, but i also support aliasing for reduce* and publishing 0.9.2 ASAP

#769

Thank you! :)

i think we will have to put this in 0.10 because some other changes have snuck in there before it. But we'll be doing that soon.

in favor of alias. Plus, reading the homepage
"While Ramda includes all of the favorite list-manipulation functions you expect, e.g. map, filter, reduce, find, and so forth, Ramda is also significantly different from libraries like Underscore and Lo-Dash."

I assumed it was still in there, but I guess with such quick iterations, it isn't easy to keep it docs up to date.