These are chat archives for ramda/ramda

15th
Mar 2018
Youngdi
@Youngdi
Mar 15 2018 02:05
Hi guys, Have everyone confused with trying to do something like "console.log([() => {}])" on Ramda PERL, which is a array have function inside and it shows [null]. Then I was like totally freak out why is [null] and waste time to debug. But ends up it is Ramda RERL's problem, not me!!!
Pedr Browne
@Undistraction
Mar 15 2018 08:33
@lax4mike it might not be, but it's certainly a reason for people not to use Ramda.
Pedr Browne
@Undistraction
Mar 15 2018 08:59
I mean in the sense that when trying to sell using Ramda in a project one of the first questions will inevitably be 'Is it performant?'. Also, I work with animation a lot and I'd love to use Ramda more in these instances (where performance is critical to maintaining FPS), so having a reference for how performant Randa's functions are compared to native would be very useful to me. I imagine they would also be useful to the authors to monitor the effect of refactoring on a function's performance.
Rolf Strijdhorst
@rolfst
Mar 15 2018 09:50
@Undistraction I think you are still missing the point when it comes to performance. when you work with animation and really need to squeeze all performance possible you should go find your fastest algorithm anyway. sometimes this helps going native, sometimes you need to use your own solution. A library is almost never a good choice when you need to squeeze top performance unless a library is tailor made for that purpose. Ramda and/or lodash are not libraries made for animation
Pedr Browne
@Undistraction
Mar 15 2018 10:20
@rolfst I don't think I'm 'missing the point' regarding performance. Looking at lodash benchmarks, some functions offer significant performance gains over native. Obviously there is no black magic going on - they are using simple loops under the hood - but benchmarks help visualise these things. There are lots of parts of an animation pipeline where performance is important in that it needs to be fast-enough and in places like this it is perfectly reasonable to use lodash or Ramda. Complex animations benefit greatly from applying fp in whatever form for exactly the same reasons other code does. Obviously within the most critical parts of a pipeline it makes sense to use a fully optimised loop using native code, but there is plenty of room elsewhere for Ramda.

From the Ramda README:

Last but not least, Ramda strives for performance.

My original question still stands. I'm interested in whether any benchmarks measuring this performance exist.

Rolf Strijdhorst
@rolfst
Mar 15 2018 10:29
well I have seen some performance benchmarks where transducers in Ramda are faster than transducers in lodash and other libraries but I haven't seen much other benchmarks
Philip Ebels
@pdme
Mar 15 2018 11:08
[shameless self-promotion] happy to hear your thoughts on a util function I wrote. compound: it's like compose, but with the rest params also passed in: https://github.com/pdme/compound
Brad Compton (he/him)
@Bradcomp
Mar 15 2018 15:35
There are some benchmarks but I don't think they are updated very often unless work on perf is being done. For the most part Ramda has very competitive performance, but there are some areas where it can be really slow for some data.
For instance, their set functions like union I think run in O(n^2)
Pedr Browne
@Undistraction
Mar 15 2018 18:26
Thanks @Bradcomp. It feels pretty fast on the whole, and for day-to-day use I've never had any problems with performance, but benchmarks would be a good tool of persuasion when it comes to convincing mgmt.
Mike Lambert
@lax4mike
Mar 15 2018 20:47
is there a more elegant way of doing fallbacks than this?
const error = {
  graphQLErrors: [
    { message: "graphql error!"}
  ],
  message: "regular error!!"
}
const errorMessage = R.path(["graphQLErrors", 0, "message"], error) || R.prop("message", error);
Brad Compton (he/him)
@Bradcomp
Mar 15 2018 20:52
R.either
Brad Compton (he/him)
@Bradcomp
Mar 15 2018 20:53
@ram-bot
const error = {
  graphQLErrors: [
    { message: "graphql error!"}
  ],
  message: "regular error!!"
}

R.either(R.path(["graphQLErrors", 0, "message"]), R.prop("message"))(error);
ram-bot
@ram-bot
Mar 15 2018 20:53
'graphql error!'
Mike Lambert
@lax4mike
Mar 15 2018 21:05
nice!
is there an equivalent to R.either that can have more than 2?
maybe i can use R.reduce....
Mike Lambert
@lax4mike
Mar 15 2018 21:12
@ram-bot
const error = {
  graphQLErrors: [
    { message: "graphql error!"}
  ],
  message: "regular error!!"
}

const fallback = R.reduce(R.either, R.F);

const getErrorMessage = fallback([
  R.path(["graphQLErrors", 0, "message"]),
  R.prop("message"),
  R.always("there was some error!")
])

getErrorMessage(error);
ram-bot
@ram-bot
Mar 15 2018 21:12
'graphql error!'
Mike Lambert
@lax4mike
Mar 15 2018 21:13
oh wow, that's a monoid or something!
Brad Compton (he/him)
@Bradcomp
Mar 15 2018 21:17
Nice!
Mike Lambert
@lax4mike
Mar 15 2018 21:18
Brad Compton (he/him)
@Bradcomp
Mar 15 2018 21:25
Love those videos