These are chat archives for ramda/ramda

2nd
Feb 2017
Matthew Willhite
@miwillhite
Feb 02 2017 03:41
@polytypic @RikuVan oh ha, that one got me for a minute…
Richard Van Camp
@RikuVan
Feb 02 2017 04:19
@polytopic, that is good to know but I don't get it really. I see merge is just curried Object.assign. So with assign I first did this in jsbin and the chrome console and isPerson is there: http://jsbin.com/jumagalizi/1/edit?css,js,console,output but in the ramda repl https://goo.gl/Im1RLe (and my original code in an app) it is not there?
Richard Van Camp
@RikuVan
Feb 02 2017 04:35
ah of course that console.log in ramda repl is only in the console...and there is isPerson
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 06:41
@rickmed Is there any published open-source projects that rely on the true FP heavily including the async stuff? It'd be great to play with something like this. And also I'd experience the first impression as a kind-of-outside-guy so I'd understand how it might feel from this perspective because I'm likely to teach it other people if I like it. :)
Martin Broder
@mrtnbroder
Feb 02 2017 08:44
Hey folks

how do you people feel about this usage of the spread operator vs concat?

[…, ...(isSomethingTrue ? [{ foo: ‘bar’ }] : [])],

vs

[...].concat(isSomethingTrue ? [{ foo: ‘bar’ }] : []),
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 09:01

@mrtnbroder I think, it's only about the readability. Personally, I find the concat version more readable at the first glance, but the spread operator is fine as well.

I'd write it as

const newArr = R.when(R.always(isSomethingTrue), R.concat([{ foo: 'bar' }]))(oldArr)

Obviously, it's better when isSomethingTrue is a function, not a boolean so you don't have to use R.always to wrap it

Martin Broder
@mrtnbroder
Feb 02 2017 10:09
I've decided to go for something like this now:
const filterTrueTuples = R.pipe(R.filter(R.head), R.map(R.last), R.flatten)

filterTrueTuples([
  [true, [{ foo: 'bar' }]],
  [false, [{ baz: 'bar' }]]
])
Aldwin Vlasblom
@Avaq
Feb 02 2017 10:18
@mrtnbroder A map followed by an unnest can just be a chain: R.pipe(R.filter(R.head), R.chain(R.last)) :)
Adam Szaraniec
@mimol91
Feb 02 2017 10:38

Hey,
I need to remove keys from object where its values are emty, nil

Should I search for keys with empty values and then use R.omit or there is already some function for that?

Hlynur Sigurþórsson
@hlysig
Feb 02 2017 10:40
Hi, is there any function/functionality for selecting random value from a list?
James Forbes
@JAForbes
Feb 02 2017 10:45
@mimol91 try R.filter(R.isEmpty, object)
Adam Szaraniec
@mimol91
Feb 02 2017 10:50
@JAForbes R.filter(R.pipe(R.isNil, R.not), object) seems to be working ok, is there any other way to do exaclly opposite to filter?
James Forbes
@JAForbes
Feb 02 2017 10:53
Did you want empty, or did you want null/undefined?
Adam Szaraniec
@mimol91
Feb 02 2017 10:53
I want to get object without empty/nil vals
R.filter(R.complement(R.anyPass([R.isNil, R.isEmpty])), data) is it ok ?
James Forbes
@JAForbes
Feb 02 2017 10:53
when you say empty, do you mean empty lists and empty strings as well?
oh ok
Yeah that's good, how bout reject instead of the complement/filter combo too?
Adam Szaraniec
@mimol91
Feb 02 2017 10:54
ahh, thx, didnt know about that
James Forbes
@JAForbes
Feb 02 2017 10:54
reject( either(isNil, isEmpty) )
my pleasure, yeah I find myself writing notNil = ... often and then remember reject! Almost daily.
anyPass/allPass is good too, I just like how either/both reads when I only have 2 cases - which is silly because anyPass,allPass make it so much easier to add cases
Adam Szaraniec
@mimol91
Feb 02 2017 10:57
ye, I like your solution
Its exacly what would I 'say' to computer to solve this problem
James Forbes
@JAForbes
Feb 02 2017 10:59
yeah :D
Rick Medina
@rickmed
Feb 02 2017 13:28
@kirillrogovoy I don't know any. Imo, you did one of the biggest steps already (ramda + promises), then you would start adding stuff bit by bit (like tasks if needed or maybe/either if you get tired of undefined exceptions getting blown up in your face). I would watch the egghead series when you have time to see what techniques are available and which ones you are interested in and all the extra powerful stuff there is
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 13:39
@rickmed Thanks for your advises. I think I will watch/read some more stuff on this topic. I asked about the projects just for examples.
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 13:45

One of the biggest challenges I faced with FP in JS is that there're always some people in the team who either have no experience with FP or just not enough. And it requires a lot of time for mentoring and code reviews. Otherwise, you are either left with half-FP/half imperative codebase of normal quality or with a lot of shitty FP code and a bunch of angry developers. :)

Maybe, I'm not just bold enough to prove FP worth investing in the long run to the stakeholders.

BasH
@bas080
Feb 02 2017 13:47
@kirillrogovoy, stop being a crusader.
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 13:47
Anyway things've been slowly changing for the last few years and FP in definitely not just for hipsters anymore. I mean for serious products with adult businesses.
BasH
@bas080
Feb 02 2017 13:48
@kirillrogovoy, also remember that OOP done properly can be easy to reason about.
It should fit the use case.
Kirill Rogovoy
@kirillrogovoy
Feb 02 2017 13:51

@bas080 I'm not a crusader, actually :) If I see FP would be a waste of time for the project I'd give it up with no regrets.

Regarding the OOP, from my experience most of people do it wrong. That's actually a reason why I got to the FP at the first place.

BasH
@bas080
Feb 02 2017 13:54
@kirillrogovoy, functional programming can be done wrong also. A technique is not gonna make you write good code. It's a combination of things. I do have to say that I find it sad that some "professional" programmers are not willing to put effort in learning new stuff.
But how to motivate someone that is not motivated.
James Forbes
@JAForbes
Feb 02 2017 14:07

@bas080 its interesting to me how much good oo code ends up looking pretty functional, e.g. uniform types, reliance on strong consistent interfaces, small classes that do 1 thing, are a lot like small functions that do 1 thing, separation of concerns. The 1 critical difference to me isn't purity but mixing logic with data / data encapsulation.

But when you think about, separating logic and data is only really a good idea when data is immutable. And if you're going to mutate data you probably want to hide that data from "the world". So the ultimate fork in the road is whether or not your data is immutable, if it isn't, then oo maybe isn't the worst idea in the world.

I'd still use FP for everything because I think FP can do everything OO can do. But good OO and good FP aren't so different really when you squint. Maybe I'm a sadist, but I kind of think Java 8 works. I think Java's obsession with interfaces combined with method bind syntax leads to some pretty nice polymorphic stream code. Yeah its pretty ugly when you compare it to a dedicated FP language, but its less ugly than you'd think it'd be considering its origins. I don't write Java anymore, but I help my brother out sometimes with some assignments and its pretty clear that the foundations laid down by interface oriented code is highly compatible with FP.

BasH
@bas080
Feb 02 2017 14:25
@JAForbes, word
Rick Medina
@rickmed
Feb 02 2017 14:30
imo, the biggest 2 differences/benefits of good fp and good oop are referential transparency and interface design based on math (Category theory), the last one really sold it for me
Stefano Vozza
@svozza
Feb 02 2017 15:23
the allowance of mutable state is the big problem for me with OO
Matthew Willhite
@miwillhite
Feb 02 2017 15:23
@kirillrogovoy Regarding your comment about mentoring and angry developers…I’d recommend you just start with one new concept that is an easy sell. Futures is a good one because it fits in easily with how people write Promises. They get used to using things like chain and map to build up their data. Then you can sneak another one in like Maybe or Either and show them how they can get rid of all these crazy logic paths. If you just go slow and accept that your codebase is going to be both declarative and imperitive in places (I mean, it is JS right?!) then I think you’ll find that things start to click for people and you end up moving your codebase into a really solid direction. I’m doing this right now with my team and it’s been going pretty well.
Stefano Vozza
@svozza
Feb 02 2017 15:23
anyone who's tried to do concurrent programming in Java will know why
Matthew Willhite
@miwillhite
Feb 02 2017 15:26
I agree it isn’t “all or nothing” as well. I actually just started by replacing underscore with ramda, which led to composition…only after 2 years working on a large codebase did I decide to bring in Futures as a better way to manage async data. And I only did it because I saw real problems with composing Promises (especially around its eagerness). So introducing an entirely new concept like Future was a big sell, but it was easy because I could demonstrate the immediate problems that it solves.
And honestly…Promises worked great for a long time. I didn’t begin the switch to Future just because I wanted something new to play with.
As an aside, thanks everyone for making ramda so great…it made me like JS again ;)
Rick Medina
@rickmed
Feb 02 2017 15:44
the other big benefit is that if you want to migrate to a different (functional) language, you will have already covered many base concepts
BasH
@bas080
Feb 02 2017 15:44
@JAForbes, I found this article which I enjoyed reading.
http://raganwald.com/2016/07/16/why-are-mixins-considered-harmful.html
Matthew Willhite
@miwillhite
Feb 02 2017 15:48
@rickmed Exactly!! What my team doesn’t know is that this is all a precursor to moving to something like Purescript (once I feel comfortable with it myself ;)
Rick Medina
@rickmed
Feb 02 2017 16:30
@miwillhite exactly my plan! muaaaahahaha!
ramda's filter(x => x) to reject false values? (ie, there is not a isFalse function)
how do i use the ram bot lol
@ram-bot
 R.without(false)(['hi', false])
ram-bot
@ram-bot
Feb 02 2017 16:35
[ 'hi', false ]
Rick Medina
@rickmed
Feb 02 2017 16:36
@ram-bot
R.without([false])(['hi', false])
ram-bot
@ram-bot
Feb 02 2017 16:36
[ 'hi' ]
Denis Stoyanov
@xgrommx
Feb 02 2017 16:48
@rickmed ['hi', false].filter(Boolean)
Rick Medina
@rickmed
Feb 02 2017 16:50
I wanted true also but that's a good alternative thanks
!
Rafi
@Rafi993
Feb 02 2017 17:35
Hi guys. One small question is process of migrating to es6 still in progress. The issue has been opened for a while and there have been some pull request regarding it.
and what version will it be done??