These are chat archives for ramda/ramda

14th
Mar 2015
Martin Algesten
@algesten
Mar 14 2015 07:58
@dannyfritz so. does coffeescript qualify as an idea? or is it just obfuscated javascript with opinionated agents?
Robin Lambertz
@roblabla
Mar 14 2015 12:14
@algesten coffeescript's idea is resumed on their website. "an attempt to expose the good parts of JavaScript in a simple way. "
Michael Hurley
@buzzdecafe
Mar 14 2015 14:59
coffeescript syntax is great, much better than verbose js. OTOH i don't like how it treats shadowed variables. cs treatment of shadowed variables is a design choice, so it is unlikely to change. also, all the sugar for class, meh, not useful to me.
Robin Lambertz
@roblabla
Mar 14 2015 16:19
I really dislike cs syntax actually. While I love python, I find coffeescript too ambiguous about what should be indented and how.
Raine Virta
@raine
Mar 14 2015 16:21
true, it takes some time to learn
Robin Lambertz
@roblabla
Mar 14 2015 16:22
I do love other aspects though. Like the return .. if .. syntax, makes for much easier to read stuff
David Chambers
@davidchambers
Mar 14 2015 16:25
Interesting when using Ramda I type function(){} so infrequently that there's little difference between JS and CS in many cases.
CoffeeScript makes imperative code prettier. Python's the same in this respect.
Raine Virta
@raine
Mar 14 2015 16:29
i've enjoyed livescript a lot, using generators can be a little awkward through
Robin Lambertz
@roblabla
Mar 14 2015 16:35
I personally enjoy using babeljs quite a lot :P
Danny Fritz
@dannyfritz
Mar 14 2015 16:35
:thumbsup: for babel
Martin Algesten
@algesten
Mar 14 2015 16:41
@davidchambers I was thinking about this just today. I was looking at this book and thought it funny that javascript functional libraries such as ramda provide very trivial functions, like lt gt. It struck me I never felt the need for them since in coffee it’s very easy to just type them yourself inline. (a,b) -> a < b
Raine Virta
@raine
Mar 14 2015 16:51
ls> map (* 2), [1 to 5] |> filter (> 5)
[ 6, 8, 10 ]
ls> reduce (+), 0, [1 to 10]
55
Robin Lambertz
@roblabla
Mar 14 2015 18:19
Is there a reduce function for objects in ramda ?
Scott Sauyet
@CrossEye
Mar 14 2015 18:21
No. The continual problem with undefined key order makes it difficult to get that right.
John-David Dalton
@jdalton
Mar 14 2015 18:22
easy enough to get right enough ;)
Robin Lambertz
@roblabla
Mar 14 2015 18:23
@CrossEye What if your accumulator doesn't care about your key order :|
I guess I could just use mapObj.
Scott Sauyet
@CrossEye
Mar 14 2015 18:26
My usual suggestion is then to reduce over toPairs. It's not quite as convenient.
mapObj is not a reduce.
Hardy Jones
@joneshf
Mar 14 2015 18:26
what do you reduce over with an object?
the keys or the values?
Scott Sauyet
@CrossEye
Mar 14 2015 18:27
mapObj(square, {a: 1, b: 2, c: 3}); //=> {a: 1, b: 4, c: 9}
Hardy Jones
@joneshf
Mar 14 2015 18:28
also, did you know that gitter supports s/old/new/g substitutions?!?
Robin Lambertz
@roblabla
Mar 14 2015 18:28
You can hack mapObj to implement reduce :P
I'll try that
And reduce over toPairs... I guess that would work
Scott Sauyet
@CrossEye
Mar 14 2015 18:28
@joneshf: most implementations I've seen want to reduce over the values, in key-order, which is odd.
toPairs will work. I don't know how you could implement foldObj on top of mapObj, as you don't get access to the keys.
Hardy Jones
@joneshf
Mar 14 2015 18:29
@CrossEye quite
Robin Lambertz
@roblabla
Mar 14 2015 18:30
@joneshf in my use-case, it's simply finding the max value of the values in an object.
object being { key: number }
Hardy Jones
@joneshf
Mar 14 2015 18:31
@roblabla do you care about the key?
Robin Lambertz
@roblabla
Mar 14 2015 18:32
nope.
wait.
nope
Hardy Jones
@joneshf
Mar 14 2015 18:32
isn't there a values thing?
Robin Lambertz
@roblabla
Mar 14 2015 18:33
hmm, true.
Hardy Jones
@joneshf
Mar 14 2015 18:33
R.max(R.values(obj))
Scott Sauyet
@CrossEye
Mar 14 2015 18:34
damn, that's easier than my first thought: R.pipe(R.toPairs, R.map(R.nth(1)), R.max). Much easier!
can't believe I forgot values
Hardy Jones
@joneshf
Mar 14 2015 18:34
if you wanted the whole object you could use toPairs as suggested
R.fromPairs([R.maxBy(R.nth(1), R.toPairs(obj))])
kind of hard to read though
so maybe a reduce is better?
or pipe it ^
R.pipe(R.toPairs, R.maxBy(R.nth(1)), R.of, R.fromPairs)
Scott Sauyet
@CrossEye
Mar 14 2015 18:38
Part of my standard answer about the problems with foldObj is this from an Underscore-like impl:
var diff = function(a, b) {return b - a;}, 
    obj1 = {a: 1, b: 2, c: 3}, 
    obj2 = {b: 2, a: 1, c: 3};
_.reduce(obj1, diff); //=> 2
_.reduce(obj2, diff); //=> 4
John-David Dalton
@jdalton
Mar 14 2015 18:39
right but that's a fabricated issue
it's again not something most run in to
Raine Virta
@raine
Mar 14 2015 18:39
does R already have something like pick but returns a list of values instead of object with picked kv pairs
John-David Dalton
@jdalton
Mar 14 2015 18:39
what's more of an issue is that Ramda buts imaginary things like this over user experience
Martin Algesten
@algesten
Mar 14 2015 18:39
you could ignore key order and make a sort function to at least have a defined order.
John-David Dalton
@jdalton
Mar 14 2015 18:39
for example the whole aliases ordeal requiring your users rewrite large parts of their project every bump
if ramda took a step back and wasn't as hardline on some things it would improve it a bit
Scott Sauyet
@CrossEye
Mar 14 2015 18:40
We have had a number of requests, but we've so far resisted, because of problems like that.
Robin Lambertz
@roblabla
Mar 14 2015 18:40
I disagree. Aliases are bad, they make for bad user experience, and is confusing.
Besides, ramda isn't yet 1.x.x, so I expect everything to break.
John-David Dalton
@jdalton
Mar 14 2015 18:41
Others don't. I know pre 1.0 is willy-room territory though.
Scott Sauyet
@CrossEye
Mar 14 2015 18:41
@jdalton: well users can choose a looser library if they prefer. We're trying to get things right, so that the consequences of your use of it is always clear
Robin Lambertz
@roblabla
Mar 14 2015 18:41
They should read up semver then :P
Scott Sauyet
@CrossEye
Mar 14 2015 18:42
I would rather that things be lawful than maximally flexible.
Martin Algesten
@algesten
Mar 14 2015 18:42
@jdalton I want object mutating functions. Javascript is mutable. It’s weird Ramda is so hardline purist in that. What do you think?
John-David Dalton
@jdalton
Mar 14 2015 18:42
lawful?
Scott Sauyet
@CrossEye
Mar 14 2015 18:43
@roblabla To be fair, people are using it in production, and have had issues. We're trying to make that easier.
@jdalton: Following easily described laws.
Hardy Jones
@joneshf
Mar 14 2015 18:43
All that needs to happen is the accumulating function has to be non-commutative, and the reduce fails over objects.
if you give it a commutative function it's no problem
Scott Sauyet
@CrossEye
Mar 14 2015 18:44
@joneshf: and we have not been interested in trying to enforce that one only passes commutative functions in. That's a law we wouldn't want to enforce.
Hardy Jones
@joneshf
Mar 14 2015 18:44
you could appease the people that want a reduce over objects by noting that their function must be commutative, otherwise the behavior is undefined
fair enough
Martin Algesten
@algesten
Mar 14 2015 18:44
or sort the keys. defined order. defined behaviour.
Hardy Jones
@joneshf
Mar 14 2015 18:44
it might need associativity also, come to think of it
that could work too
assuming they come out in the same order you put them in
also assuming keys can only be strings (i think that's true)
Robin Lambertz
@roblabla
Mar 14 2015 18:45
object keys are always strings
Martin Algesten
@algesten
Mar 14 2015 18:45
i mean it’s a common fault that people rely on that some browsers, in some circumstances, preserve key order.
Robin Lambertz
@roblabla
Mar 14 2015 18:45
(Excluding ES6 symbols)
Scott Sauyet
@CrossEye
Mar 14 2015 18:45
yes, although there are new structures in es6 that don't require that
Martin Algesten
@algesten
Mar 14 2015 18:46
but sorting them alphabetically would make it defined.
Scott Sauyet
@CrossEye
Mar 14 2015 18:46
@algesten: I would prefer that the standards insisted on this, and we could stop having this conversation! :smile:
Hardy Jones
@joneshf
Mar 14 2015 18:47
of course, that sorting adds some complexity
hmm, es6
Martin Algesten
@algesten
Mar 14 2015 18:47
@CrossEye i guess we must start lobbying the powers that be then :)
Hardy Jones
@joneshf
Mar 14 2015 18:50
@raine you could do R.invert(obj).foo
wait
that's not right
Hardy Jones
@joneshf
Mar 14 2015 19:01
var obj = R.invertObj(['foo', 'bar', 'baz']);
var pickArray = function(keys) {
  return R.pipe(R.pick(keys), R.values);
};

JSON.stringify(pickArray(['foo', 'baz'])(obj), null, 4);
[
    "0",
    "2"
]
Something like that?
Raine Virta
@raine
Mar 14 2015 19:03
exactly. how can values guarantee order?
pick-props = (props, obj) -->
  [obj[k] for k in props]
Hardy Jones
@joneshf
Mar 14 2015 19:05
that's easier to understand
Martin Algesten
@algesten
Mar 14 2015 19:08
only. that doesn’t guarantee any order.
Hardy Jones
@joneshf
Mar 14 2015 19:10
right
you can't
Eero Saynatkari
@rue
Mar 14 2015 21:11
Part of the problem with versioning is how NPM handles it. I think. I haven’t bothered reading the umpteen special rules to ^
But overall I think people are too reluctant to use 1.0. I don’t really care if Ramda is on version 18.2.0, as long as updates work expectedly
I’d go so far as to insist that a downloadable NPM package should constitute the "definition of a public api"
Scott Sauyet
@CrossEye
Mar 14 2015 21:14
@joneshf: the function would have to be associative as well:
foldObj(midpoint)({a: 1, b: 5, c: 9}); //=> 6
foldObj(midpoint)({b: 5, c: 9, a: 1}); //=> 4
foldObj(midpoint)({c: 9, a: 1, b: 5}); //=> 5
Hardy Jones
@joneshf
Mar 14 2015 21:21
so it would
Scott Sauyet
@CrossEye
Mar 14 2015 21:22
@rue: I'm not sure what you're suggesting. We're trying to get all our ducks in a row for version 1.0 so that when we're there, we won't have to make any significant breaking changes for some time.
Raine Virta
@raine
Mar 14 2015 21:24
I think he's saying 1.0 shouldn't have special semantics and module authors should just adhere to semver
Scott Sauyet
@CrossEye
Mar 14 2015 21:24
Until 1.0 we're willing to be more aggressive about making changes to our public API, but we've recently agreed to do some small things to make it easier.
Raine Virta
@raine
Mar 14 2015 21:25
npm init actually defaults to 1.0 these days to encourage that
Scott Sauyet
@CrossEye
Mar 14 2015 21:25
@raine: while I suppose that makes sense, not having a public trial period would seriously hurt.
shaking out the kinks in an API without feedback from likely users is extremely difficult.
Raine Virta
@raine
Mar 14 2015 21:27
ramda would be in double digit major version very quickly
Eero Saynatkari
@rue
Mar 14 2015 21:29
So? :) No, I think it’d be useful to just have to make more of an effort to publish 0.x series, perhaps… I’d say the vast majority of libraries and tools are fine as an initial 1.0
Metadata is another option. There’s already a need for tagging releases as security updates or serious bug fixes
Anyway, I’ll go to Twitter to complain about NPM more :)
Hardy Jones
@joneshf
Mar 14 2015 21:31
I've only recently began actually looking at ramda, have breaking changes happened in the patch versions?
@rue ^ shouldn't update you through a breaking change. Those are the semantics I gleaned from it.
if it's following semver, what difference does it make if the api breaks all the time?
Raine Virta
@raine
Mar 14 2015 21:36
according to semver, minor version increment shouldn't contain backwards incompatible changes
Hardy Jones
@joneshf
Mar 14 2015 21:38
after 1.0.x
Eero Saynatkari
@rue
Mar 14 2015 22:04
Ok, one last thing: https://nodesource.com/blog/semver-tilde-and-caret, goes over ~, ^, and < 1.0
Scott Sauyet
@CrossEye
Mar 14 2015 22:05
@joneshf: There have been a number of breaking changes. Probably the most annoying one was when we made our nearly final push to remove aliases for the library, and choosing between reduce and foldl, we chose the latter. Many, many people were not happy with that, and eventually we reversed it.
But there have been a number. Since we added the placeholder syntax to every function, we also have started dropping some flipped versions of other functions.
I'm hoping to have version 1.0 out within the next three months or so, so we really want to bottle this up tightly.
There are discussions about changing compose, pipe, and cond as well, and removing the last few variadic functions in the library. But that would also cause pain.
Hardy Jones
@joneshf
Mar 14 2015 22:24
well I can understand the frustration if it's breaking on patch versions, but if it's breaking on minor versions I'm not clear on the frustrations.
might be more situational
Scott Sauyet
@CrossEye
Mar 14 2015 22:27
We haven't been doing much with patch versions, mostly just tweaks for things we broke or forgot in our minor versions. But because we're still iterating quickly and still adding plenty of new features, people want to upgrade immediately. That's not as seamless as we would like.
Hardy Jones
@joneshf
Mar 14 2015 22:30
oh, i see
new features aren't ported to older versions then, so to get the new stuff, you have to convert everything to the new api
okay, that makes sense for frustration now :)