ramda/ramda

Practical functional Javascript

Simon Friis Vindum

@paldepind

@TheLudd I think it's controlled by git tags. You make a tag to do a release.

Jakub Korzeniowski

@kujon

just wondering - is lens composition possible in Ramda?

Jakub Korzeniowski

@kujon

just figured out the answer, it is left-to-right for lenses as explained here: ramda/ramda#1288

Ludwig Magnusson

@TheLudd

@paldepind But if you look at the tag messages of ramda, they don't contain that text

Scott Sauyet

@CrossEye

I have simply been editing the tag, including the text and making it as a prerelease. No magic.

Kevin

@kevinwshin

Why does
R.compose(R.map(R.__, [1,2,3]), R.add)(1)
not work? And what is the difference between that and
R.compose(R.map(R.__, [1,2,3]), R.identity)(R.add(1))?

Scott Sauyet

@CrossEye

This would work:

R.compose(R.map(R.__, [1,2,3]))(R.add(1));  //=> [2, 3, 4]

The original is trying to map the binary function add over [1, 2, 3], which doesn't make sense, then assuming the result is a function, and calling it with value 1.

map needs a unary function.

Scott Sauyet

@CrossEye

I'm exaggerating when I say that doesn't make sense. It returns a list of functions, essentially equivalent to [add(1), add(2), add(3)];

R.map(R.flip(R.call)(5), R.map(R.add, [1, 2, 3])); //=> [6, 7, 8]

But I don't think that's the sort of behavior you're looking for.

Kevin

@kevinwshin

I thought compose would give 1 to add, then give add(1) to map. Am I misunderstanding?

Scott Sauyet

@CrossEye

Sorry, I misread. You're right, it should, in my opinion.

I believe we broke compose in v16 or v17. I'm planning on writing up a proposal to reverse that. I was planning on doing it days ago, but life got in the way.

Kevin

@kevinwshin

Oh, good to know. Thanks for taking a look. If it helps, I think pipe is also behaving the same way.

Scott Sauyet

@CrossEye

Yes, it was the same check-in.

We're having lots of discussions right now about compose/pipe, and we need to figure out how to deal with this.

This did work in v15: http://bit.ly/1O0uEki

But it broke in 16.

ramda/ramda#1318 discusses some of the problems.

Matthew Steedman

@knubie

Hi, I'm wondering, is there a variadic version of R.concat?

Matthew Steedman

@knubie

i was attempting to write R.converge(R.concat, fn1, fn2, fn3) but instead had to write R.converge(R.concat, R.converge(R.concat, fn1, fn2), fn3)

Scott Sauyet

@CrossEye

Ramda doesn't have one. You could probably define one as:

var concatAll = R.unapply(R.reduce(R.concat, []));

And then:

R.converge(concatAll, 
           R.map(R.add(1)),
           R.map(R.multiply(3)), 
           R.map(R.flip(R.divide)(2)) 
          )([2, 4, 6]);
//=> [3, 5, 7, 6, 12, 18, 1, 2, 3]

http://bit.ly/1UkPYTi

Matthew Steedman

@knubie

I see, thanks!

trbrc

@trbrc

so. i've been using ramda for a couple of months now.

and I'm really in love with the idea. but I don't know, maybe I'm alone in feeling this... it feels like whenever I try to do anything real by composing ramda functions, i always go down a rathole.

like i'm spending hours doing something that would take minutes with some plain old imperative code.

and when I return to my code later, it seems completely incomprehensible.

is this normal? have I just not reached zen yet?

trbrc

@trbrc

i asked a question here two weeks ago or so about the best way to do something, and solved it with some help from the channel. but then it turns out... i hadn't solved it at all. the solution just randomly happened to work for the one test case i used as an example.

so despite several people looking at my snippet, not a single person was able to spot the fact that the code was not even remotely doing what i wanted to.

sorry if that sounded harsh, not what I intended to. just wanted to discuss this a bit.

is just makes me think that coding by composing functions just makes things very hard to reason about.

Scott Sauyet

@CrossEye

I'd love to hear more about where it's failing for you. My experience is precisely the opposite. By building my code out of smaller, simpler functions, I almost always find it easier to reason about.

trbrc

@trbrc

in many cases yes, it can be very elegant and expressive.

i don't know exactly what the problems i run into have in common. maybe when there are many things that need to checked or compared to figure out the final value i want.

maybe there are tools in the toolbox i should use, that i haven't figured out yet.

for the stuff i'm working on right now, there are a lot of objects/hashes, where I need to do things based both on the keys and values. that seems to bring a huge amount of friction compared to working with arrays/lists.

Scott Sauyet

@CrossEye

It might simply be that Ramda isn't well-suited for your data structures. That would be a shame, and I'd love to see if we could help, but it's certainly possible.

trbrc

@trbrc

maybe. i'm not sure how to find old messages in gitter, but that issue that i had a while back was getting the maximum value in a list, by scoring every item with a function.

here's my best attempt at doing it using only ramda.

function scoreBy(fn, list) {
    const scores = R.map(fn, list);
    const zipped = R.zip(scores, list);
    const scored = R.sortBy(R.head, zipped);
    return R.last(R.last(scored));
}

that's crazy. it seems completely opaque to me, glancing over it.

Simon Friis Vindum

@paldepind

Why can't you do R.sortBy(fn, list).

trbrc

@trbrc

that's a good question, that seems like it should work.

R.last(R.sortBy(fn, list)) ? maybe it's that simple.

Scott Sauyet

@CrossEye

.... although a sort just to find a max sounds like the wrong algorithm. If the data is small enough that should be fine.

Simon Friis Vindum

@paldepind

I agree that the current code is quite convoluted.

trbrc

@trbrc

i guess what i mean is that it feels a bit like a puzzle to me. it's easy to lose track and get lost.

this should probably be done better using reduce.

Where communities thrive

People

Repo info

Activity