lt, like I explained. It's not the end of the world, but Ramda's argument order has started to make a lot of sense to me, until I met
ltjust now. :P
gte, etc. We had
divideBy, and such, but no good names for these.
R.lt(7, 12)just seems to me it should return
divide(20, 5)should return
fnucwas built around trying to solve this issue, but I think it ends up somewhat incoherent.
R.lt(6)to test if the following value is less than 6. I think I've even used it like that to explain currying to colleagues. :P
R(x), all of Ramda's functions are partially applied with
x, and the results are returned in an object. That's an interesting way of doing things. :P
R.pipe, there's nothing special about Ramda functions; you can pass anything you want. So, while you could do something like `R(3).someRfunc, the only way I know to make it more generic so that you could apply any other function you like is with a stateful registration process.
Ritself as the function.
R.maptakes it's data last, because it's a much more common case to want to create a partially applied
mapwith a mapper, than it is to create a partially applied map with it's data, waiting for different mappers to be passed-in
fnucsince I first saw it. But I've never been quite convinced.
map(square)seems an obvious abstraction, and currying is familiar to most functional programmers in that format.
lt(x, y) !== lt(x)(y)! But I just feel the settled-upon order of arguments is wrong. I disagree with your statement that
lt(10, 12)is the only comfortable way to write "is 10 less than 12", because under that reasoning
map(arr, func)would also be the preferrable version.