These are chat archives for ramda/ramda

11th
Oct 2015
Scott Sauyet
@CrossEye
Oct 11 2015 00:06
Yeah, but Gallery Books is no O'Reilly. (Assuming you're talking about Snooki -- one of the great joys of not watching TV is to never have even hear about people like this!)
Hardy Jones
@joneshf
Oct 11 2015 00:46
I agree about Elliott, anytime you speak in absolutes you show how much you don't understand.
...
most of the time :)
Scott Sauyet
@CrossEye
Oct 11 2015 00:51
:-)
John-David Dalton
@jdalton
Oct 11 2015 08:50
No need for TV there's a podcast http://www.podcastone.com/Naturally-Nicole
I know too much...
Stefano Vozza
@svozza
Oct 11 2015 11:24
sorry for the rewind but catching up on the people complaining about moment.js: a friend of mine has started a more functional date library. it's missing lots of features but the aim is to do most of what moment does without the madness.
Raine Virta
@raine
Oct 11 2015 11:25
nice
Frederik Krautwald
@Frikki
Oct 11 2015 11:47

@joneshf anytime you speak in absolutes you show how much you don't understand

That is such an absolute statement :D

Scott Sauyet
@CrossEye
Oct 11 2015 12:58
@Frikki: yes, but either originally meant ironically or immediately noticed and corrected.
Frederik Krautwald
@Frikki
Oct 11 2015 12:59
@CrossEye And quite funny.
Scott Sauyet
@CrossEye
Oct 11 2015 13:00
@jdalton: Great... one more thing to avoid. I refuse to look. I won't look. I'm not going to... damn it all.
Frederik Krautwald
@Frikki
Oct 11 2015 13:01

It reminds of the statement:

Everything is relative

Which is also quite absolute.

Scott Sauyet
@CrossEye
Oct 11 2015 13:02
well, relatively absolute. :)
Raine Virta
@raine
Oct 11 2015 13:02
Everything is relative, except this statement
Frederik Krautwald
@Frikki
Oct 11 2015 13:02
Precisely
Scott Sauyet
@CrossEye
Oct 11 2015 13:03
  1. The following statement is false.
  2. The preceding statement is true.
Hofstadter, here we come.
Scott Sauyet
@CrossEye
Oct 11 2015 13:15
More about Eric Elliott's rtype ideas, and direction: https://github.com/ericelliott/rfx#getting-started. First impression: <shudder>. "Let's take all the metadata one might ever want to know about a function and wrap it in a new way to define functions, burying the lede (the actual function definition) way down in paragraph 6."
Hardy Jones
@joneshf
Oct 11 2015 13:49
I think it's kind of a good start, but it doesn't actually solve any problems.
The only field that depend on another is the fn field it seems.
fn depending on type I mean.
All of the others can get out of sync.
So this is no better than any other approach.
It still requires a human to ensure things are correct.
And really, that's a lot of fuss for a contract library.
More to the point, all fields except for fn are optional.
Laziness will cause people not to fill in those optional fields.
Scott Sauyet
@CrossEye
Oct 11 2015 14:19
Three of the fields, description, doc, example have little to do with type definitions, and more to do with some of the other goals of helping with tooling, run-time access to metadata, documentation generation. While these might be worthy goals, I already hate cluttering my source file with metadata. Cluttering the actual runnable part of the source itself with this just sounds horrible.
Hardy Jones
@joneshf
Oct 11 2015 14:37
All of that information is the type definition though.
If you're working with a language that has a shitty type system, your documentation becomes your type system.
It's human checked though, which is the problem
Frederik Krautwald
@Frikki
Oct 11 2015 14:38
The problem I see is that people try to patch the "bad" parts of JavaScript to make it another language but without actually making another language.
Hardy Jones
@joneshf
Oct 11 2015 14:38
exactly!
Raine Virta
@raine
Oct 11 2015 14:39
you are saying there is no hope for JavaScript
Hardy Jones
@joneshf
Oct 11 2015 14:39
and js just isn't powerful enough to make that a worthwhile effort.
Frederik Krautwald
@Frikki
Oct 11 2015 14:54
@raine I really don’t see that JavaScript not being type safe has to be viewed as something that needs fixing at all. There’s plenty of hope for JavaScript. ES6, for example, works wonders with its modularity. I do, however, find that the class implementation is unnecessary, and I avoid it as much as possible.
Hardy Jones
@joneshf
Oct 11 2015 14:55
@Frikki you might not be saying it, but I sure am :). And I'm not sure which of us @raine was talking to.
Scott Sauyet
@CrossEye
Oct 11 2015 14:56
I see trying to force JS to act like a strongly-typed language as pretty much a waste of time. But there are plenty of useful things that can be done in JS without that.
And that doesn't mean that we can't make our own functions more strongly typed than some others.
Ramda avoids optional parameters, and generally tries to keep to single types for each parameter (at some level of abstraction.)
It'll never be Haskell or ML, but that's ok.
Scott Sauyet
@CrossEye
Oct 11 2015 15:02
@joneshf: As to those fields being the type system, I understand what you're saying, but this system explicitly dedicates another field to the type, and uses another (so far barely written) spec for the type details. That's how it wants to understand types, as I understand it. The remaining fields are, I believe, designed for other, perhaps overlapping, purposes.
Frederik Krautwald
@Frikki
Oct 11 2015 15:35
If people don’t feel JavaScript is good/strong enough, then people should choose a different language to write their programs in and then compile to executable JavaScript.
David Chambers
@davidchambers
Oct 11 2015 15:59

I see trying to force JS to act like a strongly-typed language as pretty much a waste of time.

Do you mean strongly typed or statically typed, @CrossEye? Taking steps to prevent type coercion—disallowed by many dynamically typed languages—seems reasonable to me!

Scott Sauyet
@CrossEye
Oct 11 2015 17:30
statically typed is of course what I meant, but I'm not even entirely in agreement with you on coercion.
David Chambers
@davidchambers
Oct 11 2015 17:34
Do you believe 'foo' + 42 should be a valid JavaScript expression?
Frederik Krautwald
@Frikki
Oct 11 2015 18:53

Do you believe 'foo' + 42 should be a valid JavaScript expression?

This reminds me of the question: Should there be pointers in C++?

The question cannot be "what should be valid" in an existing language, because that’s the way the language is designed. It would make much more sense to ask: Do you believe 'foo' + 42 should be a valid expression in the new [fill in name of language] we are designing?

David Chambers
@davidchambers
Oct 11 2015 18:54
Should have been would have been a better phrasing.
Scott Sauyet
@CrossEye
Oct 11 2015 19:25
What do you mean by "a valid JavaScript expression?" :smile:
David Chambers
@davidchambers
Oct 11 2015 19:25
Should it have been a type error at run time, as in Python?
Scott Sauyet
@CrossEye
Oct 11 2015 19:39

I don't know if there would have been ways to make the rules simpler and avoid the crazy edge cases we have now, but I am definitely in favor of the language doing coercion to Strings for string concatenation, I don't mind casting to number for other arithmetic operations. But clearly the rules have many crazy cases, and I've never investigated to see if that is a matter of sloppiness or is fundamental to the idea of coercion. There are plenty of languages I can choose from that disallow this; I like also having ones that offer:

'user is ' + user.age + ' year(s) old.'

for when I want it, and don't make me do something like:

'user is ' + String(user.age) + ' year(s) old.'
David Chambers
@davidchambers
Oct 11 2015 19:47
I'm not sure whether it's possible to allow just the "good" coercion.
On a different note, I've just posted the 0.18.0 upgrade guide! ramda/ramda#1436
Frederik Krautwald
@Frikki
Oct 11 2015 19:54
And the beauty of ES6: `user is ${user.age} year${user.age > 1 ? `s` : ``} old`
@davidchambers I see mapObj is depreciated, does this also include mapObjIndexed?
David Chambers
@davidchambers
Oct 11 2015 20:03
No. R.map now has the ability to transform an object's values, but in cases where the function requires the key in addition to the value one must use R.mapObjIndexed.
James Forbes
@JAForbes
Oct 11 2015 23:02

Hey guys!

Say you have an array [ x,y ] what would be the simplest way to convert it to an object { x,y } in ES5

I mean, other than
function xy(list){
  return { x: list[0], y: list[1]}
}
Denis Stoyanov
@xgrommx
Oct 11 2015 23:11
@JAForbes R.zipObj(['x', 'y'], [1, 2])
Hardy Jones
@joneshf
Oct 11 2015 23:11
mergeAll(zipWith(createMapEntry, ['x', 'y'], [x, y]))
or that. :)
I didn't know about zipObj
I wonder why something like that exists, but other helper things don't.
Scott Sauyet
@CrossEye
Oct 11 2015 23:13
Helpers created when requests come in that seem to resonate with maintainers. No particular design.
These are Ramda answers. Can't think of any particularly ES6 things to help. All the destructuring stuff goes in the other direction. Don't know that there's something particularly useful for this.
But not an expert... far from it.
Denis Stoyanov
@xgrommx
Oct 11 2015 23:15
R.fromPairs([['x', 1], ['y', 2]]) :smile:
James Forbes
@JAForbes
Oct 11 2015 23:32

@xgrommx both great answers. Thank you.

@CrossEye does R.indexBy resonate?

James Forbes
@JAForbes
Oct 11 2015 23:38
@CrossEye destructuring could do something like: ([x,y]) => ({x,y})