These are chat archives for ramda/ramda

21st
Sep 2016
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 09:57

Hey, does someone know why

const res = R.pipe(makeResponse, e => Promise.resolve(e));

works but :

const res = R.pipe(makeResponse, Promise.resolve);

throws a TypeError?
21-09-16 09:57:29 - error: ERROR: TypeError: function resolve() { [native code] } called on non-object

makeResponse just returns an object with 2 fields… so no magic there….

Denis Stoyanov
@xgrommx
Sep 21 2016 09:59
@MarkusPfundstein makeResponse is promise? do u have full example?
Syaiful Bahri
@syaiful6
Sep 21 2016 09:59
it's mostly because context this
Denis Stoyanov
@xgrommx
Sep 21 2016 10:00
@MarkusPfundstein R.pipe(makeResponse, R.bind(Promise.resolve, Promise))
or R.pipe(makeResponse, Promise.resolve.bind(Promise))
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 10:01
no makeResponse is just
const makeResponse = r => {
     return { statusCode: r.statusCode, …. }
};
`
ok the bind thus.. why is this necessary? I thought Promise.resolve is a static method
Denis Stoyanov
@xgrommx
Sep 21 2016 10:01
@MarkusPfundstein context
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 10:01
w.r.t to the Promise library that is used?
Syaiful Bahri
@syaiful6
Sep 21 2016 10:01
it maybe trying to access it constructor..
Denis Stoyanov
@xgrommx
Sep 21 2016 10:02
no, in your case context is window, but with bind we can change our context to Promise
window doesn't has resolve method
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 11:26
its NodeJS, but still same thing I guess
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 12:35
Is there a good way to avoid mentioning the object name twice in this concatenation: obj.a + obj.b. See my example: https://goo.gl/Jhkr8z
I've used apply with concat here: https://goo.gl/Dk3TM1
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:29
@aaronmcadam There's always converge ;) https://goo.gl/0j1kG1
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:29
haha it's always converge! :D
Denis Stoyanov
@xgrommx
Sep 21 2016 16:30
or lift
lift(concat)(prop('pathname'), prop('search'))(redirectLocation)
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:33
Will converge help with this too @Bradcomp :D :D :D https://goo.gl/lWwTg3
So I'm trying to build a function that will take a list of keys. It should then read off the params key and pick off the list.
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:37
So like a nested pick?
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:38
sorta yea
const getParams = keys => compose(pick(keys), prop('params'));
The only small downside is that I've gotta call that function twice as seen in my REPL example
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:39
curry((keys, obj) => compose(pick(keys), prop('params'))(obj))?
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:40
ah, so we embed the calling inside the curry
I kept getting tripped up on the function being unary :)
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:41
I mean, then you can call it either way.
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:42
yeah, I was trying to use curry to get that earlier but I hadn't thought to add the extra argument (obj)
thanks @Bradcomp!
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:43
:+1:
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:44
just a style thing, what's a better order to put arguments? Things that change more to the right?
So in this example, you could say that the obj is more static than the keys being picked off right?
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:45
yeah. Functions to the left, data to be operated on to the right. Things that change more to the right. Things you want to 'bake in' via currying to the left
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:46
Cool, so this function would be a bit more flexible if the args were obj, keys instead of keys, obj
I know I could always flip if I needed to
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:47
Well, will you need to pick different sets of keys off the same object, or are you more likely to pick the same set of keys off different objects?
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:49
I'm more likely to pick different keys off the same object. In this case, it's in a node routing middleware so the obj is req which doesn't really get used again and I can't really curry it and pass it around to the different handlers.
But I think the idea still holds
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:50
Well in that case I would flip the argument list
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:51
So func(obj, keys) in this example?
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 16:51
yeah
Aaron Mc Adam
@aaronmcadam
Sep 21 2016 16:51
Cool, makes sense, thanks again :)
Juan Soto
@sotojuan
Sep 21 2016 16:58
Off-topic: does anyone here use Fluture ?
if so, what do you use to make HTTP clients? most things out there return promises
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 17:01
@sotojuan Have you seen Futurize?
Juan Soto
@sotojuan
Sep 21 2016 17:02
yes, but whats a good callback-based http client? request is pretty bloated imo, dont like it
Brad Compton (he/him)
@Bradcomp
Sep 21 2016 17:05
I've used Axios (Promise based) with some success.
Rick Medina
@rickmed
Sep 21 2016 17:54
fun task + superagent?
Juan Soto
@sotojuan
Sep 21 2016 18:42
@rickmed super agent is a bit better than request, might end up with that one
promise-returning ones dont count bc you might as well just not use futures by then :p
Rick Medina
@rickmed
Sep 21 2016 19:12
@sotojuan most of the libraries I researched were promise based. If you find something better pls post :)
Nate Abele
@nateabele
Sep 21 2016 19:25
Anybody know if any Fantasy Land shims exist for ES6 Map/Set/etc.?
Juan Soto
@sotojuan
Sep 21 2016 19:51
@rickmed yeah it sucks—im actually thinking of writing one that returns futures for fun, maybe ill get around to it
LeonineKing1199
@LeonineKing1199
Sep 21 2016 19:59
I'd maybe try to avoid things like Promise chains and Futures for the same reason as they won't be as async await friendly.
Juan Soto
@sotojuan
Sep 21 2016 20:00
async await works with promises no? you can do await fetch('/hello')
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:01
Yeah, you "await" promises
You can still mimic the functional compositions but you no longer need to wrap everything in the context of binding functions repeatedly to a Future
Juan Soto
@sotojuan
Sep 21 2016 20:02
right
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:02
JS' native Promise is nice because the then method is like map and chain mixed into one
You don't need to explicitly flatMap anything, it just does it all for you.
Rick Medina
@rickmed
Sep 21 2016 20:09
many think then vs map/chain is a con instead of a pro -it was one of the reasons why fantasy land was created while defining the promise/A+ spec. There was a chat about it in the fantasy land gitter not long ago
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:09
Really?
Eh.
then is more resilient to refactoring, imo
It also reduces cognitive overhead. You don't need to ponder about whether you're mapping or binding
Rick Medina
@rickmed
Sep 21 2016 20:10
if you are interested....promises-aplus/promises-spec#94
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:11
Promises are already largely monadic.
I guess if they take two functions, it means their dyads?
Even then, I feel like applying category theory is more effective in a statically typed language.
JS is pretty much orthogonal to types.
Juan Soto
@sotojuan
Sep 21 2016 20:11
throwback to this long and etertaining read promises-aplus/promises-spec#94
oh lo
already linked
thats what i get for not reading
fwiw i see futures as fun to mess around with and try, not saying theyre better than promises
and i wanted to make some http requests that use them :p
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:12
I'm a co fanboy.
You can still exploit all the functional constructs you can write your async code in a synchronous way
Juan Soto
@sotojuan
Sep 21 2016 20:13
yeah i use co in my projects as well
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:13
Now whenever I see a Promise chain, I'm just like, "Whoa, retro"
Juan Soto
@sotojuan
Sep 21 2016 20:13
until async await is in node without babel ill use co
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:13
That's why TJ made it
TJ, the JS sex god
Juan Soto
@sotojuan
Sep 21 2016 20:13
im lucky that i dont need to frontend JS so my build steps dont exist
Drew
@dtipson
Sep 21 2016 20:14
@LeonineKing1199 pondering about that is important, because it's specific/predictable
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:14
How so?
I mean, it definitely is more meaningful when read.
You can instantly see which function does a pure mapping vs which one returns another action
Drew
@dtipson
Sep 21 2016 20:15
At least, how I think about it you match up type signatures of functions to the interfaces you're using
in practice, I agree that .then's behavior doesn't often cause a problem. But it creates a weird gotcha
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:15
And what's that?
Drew
@dtipson
Sep 21 2016 20:16
You can create a Promise.of = x => Promise.resolve(x)but it's not strictly lawful
it will work in most cases, but not if you try to make x a Promise
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:16
I don't know if JavaScript and strict belong in the same sentence XD
Drew
@dtipson
Sep 21 2016 20:16
true
but laws ~== predictability
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:16
Brb, trying Promise.of(Promise.resolve())
Oh wait, my bad; I'm an idiot
there's no Promise.of XD
Drew
@dtipson
Sep 21 2016 20:18
One thing you can always be sure of if you have a lawful .map() is that the Type.of(x).map(fn) operation itself won't examine or do different things based on what x is
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:18
I actually like the Promise object because it doesn't attempt to adhere to any sort of specification like that
I love me some interface-based programming but you really can't do it in JS
Drew
@dtipson
Sep 21 2016 20:18
but that's exactly what .then does: it examines the inner value and does different things depending (map behavior or flatMap/chain behavior)
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:18
That's true. But to me, that's almost advantageous
The good news though is that is a moot point in the wake of async await
Drew
@dtipson
Sep 21 2016 20:19
I mean, I mostly agree: in practice, 1) you almost never need to maintain Promise[Promise[x]] as a useful structure: you're always going to want to mjoin them
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:19
We'll no longer need Promise chains
Then to this end, you can write everything almost in terms of pure map's
Drew
@dtipson
Sep 21 2016 20:20
and 2) it's impossible to sequence Promise[Array[x,y]] into Array[Promise[x],Promise[y]]
because until the Promise resolves, there's no way to know how many elements in the Array there should be.
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:21
That is true, you can't sequence a Promise of arrays to an array of Promises
Drew
@dtipson
Sep 21 2016 20:21
You're right tho. If you read that A+ thread, I think that's part of why .then = .map||.chain is a secondary concern to the FL folks. It's weird, but mostly you can just be careful
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:22
Truth be told though, I've actually never actually needed such functionality XD
The problem I encountered the most with Promise chains was trying to incorporate results from previous actions into current actions
Drew
@dtipson
Sep 21 2016 20:22
Right. The opposite though, is super common of course, and Promise.all is it
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:22
co was a really great solution for that because everything was still visible to everythign else.
If you need to pass along multiple variables, you can, and that's exactly what sequence gives you the ability to do
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:24
I've seen that before but I think it works better in languages that actually embrace tuple-types and have the ecosystem designed around that
Drew
@dtipson
Sep 21 2016 20:24
though of course, higher-level abstractions like co can make that readable in another fashion
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:24
Like, Haskell and C++ would catch you and slap you in the face for accessing a tuple incorrectly.
In JS, it's just like, "Nah, man, we gon' keep goin'"
Exactly in that voice too
I also feel like passing the array around isn't as maintainable
Drew
@dtipson
Sep 21 2016 20:25
the main win of tasks/Future/flutures/etc, over Promises, aside from just speed, is the laziness.
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:26
Promises aren't lazy?
Drew
@dtipson
Sep 21 2016 20:26
they kick off when they're created, as opposed to when they're needed
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:27
That sounds advantageous from a performance perspective though
Drew
@dtipson
Sep 21 2016 20:27
I also think having a type signature that basically forces you to deal with errors is pretty sound
I mean, I use Promises all the time, not knocking them. But there's pretty much nowhere they aren't inferior, imo, to the alternatives other than they don't require pulling in an extra library.
You can define Promise.ofthough, I do it all the time. Not aware of a drawback: it's just a syntax thing, keeps them in line with other type constructors. As long as it's understood that they automatically unnest
Juan Soto
@sotojuan
Sep 21 2016 20:32
cool dudes use callbacks
Drew
@dtipson
Sep 21 2016 20:33
Promise.of = x => Promise.resolve(x)
Promise.prototype.concat = function(that){
 return Promise.race([this,that]);
};
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:34

cool dudes use callbacks

They are the most performant :laughing:

Drew
@dtipson
Sep 21 2016 20:35
You can add a bunch of the FL methods to Promises, for fun/education/a common interface when you have a bunch of other types. In production though, I say use a lazy, well-tested FP version
You can even fix the argument order in .then to have the error first, and have errors in the success branch switch over to the error handler in the second:
Promise.prototype.bimap = function(e,s){
  return this.then(s).catch(e);
};
LeonineKing1199
@LeonineKing1199
Sep 21 2016 20:36
Eh. To me it seems like it has the smallest amount of cognitive overhead to embrace the async await style and stick with synchronous constructs. But that's just, like, my opinion, man
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:02
we have the same discussion at my company
some think FP, some imperative
some love await/async, others promise chains
funny enough the await/async code is mostly unmaintainable after a while due to all state. Promise chains kinda force you to think in strict I->O function behaviour while await/async encourages programmers to program js like its C.
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:04
Hmm... I think that's more a symptom of your code not being modularized.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:05
no no code is super modularized
its small things
I think its more of a mindset issue though.
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:13
I think it is. Keep in mind, C is a popular and powerful language used to write entire operating systems.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:18
yes and encoders, and microcontroller. but Js is very different and with all the computing power, its just BS to say stuff like: I mutate my object because thats more efficient than to make a deep copy. Dude , if we have too much requests we add a server. Developer time is more expensive than that.
A month ago I tracked down a bug because we had some object that was used as a cache.. A big tree essentially. Somewhere in a very deep function, someone modified a leaf of that tree. Which of course then resulted in issues for all subsequent calls to the cache….
Get your leaf, make a deepClone, work with that...
expensive my ass.. my salary is expensive :-)
clojure gets it right though.. but js is everywhere...
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:24
O_o
Did you know C had a const keyword?
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:26
did you know the earth is not the center of the universe?
sry, I dont get your point.
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:26
I actually don't get yours.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:26
:-)
now we are two
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:26
Keep in mind, the Linux kernel is incredibly stable. And powerful.
There's no one perfect language.
I'm sorry someone wrote bad code at your company.
But don't blame C.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:27
na man its not about the language
i love C
its elegant and small
my point is
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:28
const-qualification matters?
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:28
i think Promises encourage FP, which I think is POSITIVE!!! Async/await encourages imperative programming, which I think is NEGATIVE. especially in languages like JS!
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:28
Oh, you're one of those.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:28
imperative programming has its place but I think the future of JS should be functional.
phew. hard time
I found that ex-C/embedded programmers who switch to JS love async/await :-) Because its lets them write code that looks like what they are used too..
but ok… nvmd , its late in Europe
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:30
You can use async await with functional constructs though.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:30
i know
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:30
It was never implied that they were mutually exclusive'
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:30
no luckily not
but sometimes language constructs emphasize certain styles
like Haskell, which kinda forces you down the pure FP route with Monads and stuff.. Or java, which kinda forces you to do OOP
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:31
Yeah, that's my least favorite part of Java.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:32
js lets you do everything though. which is nice. It would be cool if FP would be more in the center of attention :-) But last conference I attended, every one was crazy about async/await and only a small group about Promises..
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:32
Because synchronous code is easier to reason about.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:33
no, its easier to get down into vim… the reasoning stuff that comes later is harder
you mean imperative top/down code
its still async of course, just somehow squeezed into the language eto look like its synchronous
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:34
I actually think co implementation is really close to the real thing. I'd be interested to read about how the runtime implements it without generators.
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:34
do you know synchronize?
thats also quite nice
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:34
Is that a module?
we use it in production since a year or so
works flawlessly. I digged a bit into the code. I think it works with threads
but no idea how he acutally does it
LeonineKing1199
@LeonineKing1199
Sep 21 2016 21:36
Maybe. I'm not sure how it works but I do know that you can only have one instance of V8 at a time that you pass around as an "isolate"
Markus Pfundstein
@MarkusPfundstein
Sep 21 2016 21:38
i dont know :-) off to bed now. good night