These are chat archives for ramda/ramda

20th
Sep 2015
Asaf
@asaf-romano
Sep 20 2015 05:37
how is coroutine different from other libraries (and ES7's async/await)?
Scott Christopher
@scott-christopher
Sep 20 2015 07:15
Perhaps in the absence of a common Maybe type, Ramda could offer a headOr :: a -> [a] -> a function which returns the first argument for an empty list?
hemanth @hemanth would like to thank everyone who gave a quick feedback on the jargon! Much appreciated.
Martin Algesten
@algesten
Sep 20 2015 10:16
Is there a ramda way of invoking a function only if the argument is truthy? Something like
R.ifElse(R.identity, fn, null);
Raine Virta
@raine
Sep 20 2015 10:20
like maybe from allong.es, not sure there is
Martin Algesten
@algesten
Sep 20 2015 10:25
hm. can allong.es maybe be confused with Maybe(a) monad fantasyland style?
i mean this is likely just me being confused.
Raine Virta
@raine
Sep 20 2015 10:27
I think it might be pretty clear from the context which one it is
maybe is like poor man's Maybe
Martin Algesten
@algesten
Sep 20 2015 10:32
but then, wrapping every conceivable value in a container because it may be null, is like not wanting to program javascript?
Raine Virta
@raine
Sep 20 2015 10:33
rather like wanting to make failure explicit
Martin Algesten
@algesten
Sep 20 2015 11:01
a lot of work for dividing some numbers... i really would want to see how this works in practice. are there any semi-large to large projects around that use this style programming in like a back end service doing something more complex? seeing is believing :P
Raine Virta
@raine
Sep 20 2015 11:22
to me the use of algebraic types in JS still seems like an exploratory phenomenon, the benefits can seem questionable in non-typed world. I have used Maybe in small scale and in my opinion have ended up in solutions that were more elegant than otherwise would've been.
hemanth @hemanth shudders TOC in a blog post!
Martin Algesten
@algesten
Sep 20 2015 11:53
i feel javascript is liberating exactly because it is non-typed, mutable, falsey/truthy, etc. pretty much the stuff that some functional purists dislike are the things i like. after years of programming typed languages, it's so refreshing.
it's funny reading robotlolitas post where they feel the need to point out that + both concatenates strings and adds numbers.
hemanth.hm
@hemanth
Sep 20 2015 11:57
@raine Nice find, one of the best articles I have read on mondas, just tweeted it :) :+1:
hemanth.hm
@hemanth
Sep 20 2015 12:09
Do we have plans to have laziness in Ramda? Like a take method?
And any idea of having parallelism as well?
Martin Algesten
@algesten
Sep 20 2015 12:25
seems to be a discussion on lazy #446 #878
and the transducers seems to be there...
Simon Friis Vindum
@paldepind
Sep 20 2015 13:00

@aglesten

but then, wrapping every conceivable value in a container because it may be null, is like not wanting to program javascript?

That's a strawman. No one is suggestion that every conceivable value should be wrapped in maybe.

@CrossEye @davidchambers Wasn't our old compose/pipe very similar to a "assume every function is unary"-compose? The only difference was in the length property of the returned function.
Simon Friis Vindum
@paldepind
Sep 20 2015 13:06
I.e. our old compose worked perfectly in the only-unary functions case?
Martin Algesten
@algesten
Sep 20 2015 13:18
@paldepind fair enough. i see the Maybe/Just etc stuff and can't say I feel that warm fuzzy feeling. however it may be all down to me not getting it yet.
i remember @CrossEye saying somewhere somewhere that he was happy with the way ramda's dispatch works. after reading the internal _dispatcher code, i think i get it. on that note – does someone have a similarly good blog like the robotlolita/monad one on transducers?
Martin Algesten
@algesten
Sep 20 2015 13:24
thanks! time for rosé, hula hoops and transducers. :D
Ludwig Magnusson
@TheLudd
Sep 20 2015 13:28
@algesten What do you really want in the null case? R.ifElse(R.isNil, R.identity, fn) will return the result of the function call if the value is not null. Otherwise you will still have null..
The reason there is no "only if" function in ramda is that the function needs to return something.
Martin Algesten
@algesten
Sep 20 2015 13:32
@TheLudd hm. interesting. yes. it's almost side-effect-ish the way i'm thinking. in guess i want null. or undefined. but your example does that.
Ludwig Magnusson
@TheLudd
Sep 20 2015 13:33
In fact R.ifElse(R.isNil, R.identity) could work as a kind of "poor mans maybe". Pass a function to it and you will have a null check version of that function. Where Maybe gives you Nothing this will safely keep returning null to you.
Martin Algesten
@algesten
Sep 20 2015 13:35

yes. but if we entertain the idea that i'm not quite ready wrapping my values in Maybe (just yet ;)) ... then i do have a lot of NPE-avoiding code. off the top of my head, i often write stuff like:

b = some?.deep?.fun?(a)
b.map(something) if b

etc

Ludwig Magnusson
@TheLudd
Sep 20 2015 13:36
That was my point. You can use R.ifElse(R.isNil, R.identity) to aviod the need for Maybe
Martin Algesten
@algesten
Sep 20 2015 13:36
perhaps coffeescript is shielding me from the hard reality :smile:
yes. thanks for the R.ifElse goes into useful bits of code.
Ludwig Magnusson
@TheLudd
Sep 20 2015 13:37
coffee-script has a lot of syntax to do common stuff quite easily. I used to do coffee script more in the past but I am moving away from it because I beleive tha syntax is bad :)
It is not reusable...
Raine Virta
@raine
Sep 20 2015 13:39
S.fromMaybe('default', S.gets(['deep',  'fun'], some).ap(a).map(something))
Martin Algesten
@algesten
Sep 20 2015 13:39
well. i like significant whitespace and that everything returns something. it's kind of the last bits I want in ES2016
Ludwig Magnusson
@TheLudd
Sep 20 2015 13:39
You can still do CS without all the fancy stuff :)
Martin Algesten
@algesten
Sep 20 2015 13:40
@raine thanks!
Martin Algesten
@algesten
Sep 20 2015 13:46

this transducer blog post. stuff like into(to, xform, from) it says

apply xform to each value in the collection from and append it to the collection to

doesn't this make fp-people cringe?

that "append" is a mutation, surely?
Ludwig Magnusson
@TheLudd
Sep 20 2015 13:52
FP people always assume there is no mutation so when it says append it means "return a new instance with the element appended"
just like R.append
Martin Algesten
@algesten
Sep 20 2015 13:54
alright.
Hardy Jones
@joneshf
Sep 20 2015 18:39

@algesten

i feel javascript is liberating exactly because it is non-typed, mutable, falsey/truthy, etc. pretty much the stuff that some functional purists dislike are the things i like. after years of programming typed languages, it's so refreshing.

I think years of programming with a simple type system like most of the ALGOL based languages (C/C#/Java/etc) have will do that to anyone.
Years of programming with a better type system like the ISWIM based languages (ML/Haskell/PureScript/etc) have will generally do the opposite.

Martin Algesten
@algesten
Sep 20 2015 19:18
:blush: yes. it may very well be I haven't encountered what it's like. my latest throwback was doing swift for an iOS app. they clearly took impression of Maybe with their optionals, but it's so painful. it's absolutely impossible to use any API without the incessant control compilation-as-you-type of their dev environment. well. I like emacs. i still haven't seen a way of doing strong typing with a big API like cocoa or java.lang, without the need of a special editor.
and this is the thing. strong typing is nice for the simplest of problems. but how does it work in a big ecosystem of APIs?
David Chambers
@davidchambers
Sep 20 2015 20:34
@algesten, I imagine static type systems are most beneficial in large systems. Simon Peyton Jones has talked about Haskell's type system enabling him to refactor GHC with confidence (for decades by this point). Were GHC written in a dynamically typed language I imagine SPJ and other contributors would have been less inclined to refactor the codebase over the years, since refactoring is less fun in such an environment (even with complete test coverage). Finding type errors by tracing test failures backwards through stack traces is less convenient (and likely more time consuming) than having a compiler point out the precise locations of type mismatches.
Martin Algesten
@algesten
Sep 20 2015 20:38
yes. @davidchambers, refactoring and renaming with confidence is an advantage, but not enough to tip the balanace. luckily, for me, the nodejs thing arrived simultaneously micro services. these days i very rarely find myself doing the kind of refactoring that was commonplace when i used to work on those big monoliths of java-code.
Raine Virta
@raine
Sep 20 2015 20:39
with static typing you could enforce semantic versioning by finding type changes in APIs
David Chambers
@davidchambers
Sep 20 2015 20:39
That's so cool! Elm does this, I believe.
Scott Sauyet
@CrossEye
Sep 20 2015 21:34
@hemanth: We had a lazy list extension from the very early days. We pulled it out in #857 as it wasn't really getting any love. I would like to see it again, but am not really interested in putting the effort into it at the moment.