4 ms·

And what is that?

janehdoch 3y ago
[flagged]
gorgoiler 3y ago
Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.
eddythompson80 3y ago
https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide Basically flipping around the args in a function and returning a "curried" function call. So instead of _.map(["1"], parseInt) it's the other way around, _.map(parseInt, ["1"]) That way you can do something like const parseArrayFunc = _.map(parseInt) const parsed = parseArrayFunc(["1"]) This pattern is called currying in functional programming.
- kristjansson 3y ago
  The complaint, I would think, being with the machinery to make _.map return a function or a value depending on the number of args, not with the flipping/arg order stuff?
  - deleted 3y ago
    [deleted]
  - eddythompson80 3y ago
    Yeah I’d think so too. FP languages like Haskell or F# has partial application as part of the language itself and you get it for free by just ordering the parameters that way.
- gorgoiler 3y ago
  Partial application makes sense to me as a useful computer science concept. Reasoning about functions when they always have 1-arity makes proofs possible. In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites: def serialize(fn, data, path): … yamlize = partial( serialize, yaml.dump ) jsonize = partial( serialize, json.dumps ) Presumably some of these people wake up in a cold sweat about the shame of typing “partial(serialize, …)” twice and do this: def serialize(fn, data, path): … a = lambda f: partial(serialize, f) yamlize = a(yaml.dump) jsonize = a(json.dumps) A good example of Don’t Repeat Yourself mutating into Never Repeat Yourself with ill effect, because the developer has self flagellated so much that the following code is deemed to have too much repetition in it: def write(data, path): … def write_yaml(data, path): write(yaml.dump(data), path) def write_json(data, path): write(json.dumps(data), path)
RedNifre 3y ago
As an illustration, I wrote a Sokoban game in that style (no mutation, no side effects, partial application everywhere). See https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game.js https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game...

And what is that?

[flagged]

Specifically I don’t know, though I do know what currying is. This auto-currying thing sounds like a reaction against some parts of JavaScript where you can get burned by default arguments. A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs. Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.

eddythompson80 3y ago

https://github.com/lodash/lodash/wiki/FP-Guide https://github.com/lodash/lodash/wiki/FP-Guide Basically flipping around the args in a function and returning a "curried" function call. So instead of _.map(["1"], parseInt) it's the other way around, _.map(parseInt, ["1"]) That way you can do something like const parseArrayFunc = _.map(parseInt) const parsed = parseArrayFunc(["1"]) This pattern is called currying in functional programming.

kristjansson 3y ago
The complaint, I would think, being with the machinery to make _.map return a function or a value depending on the number of args, not with the flipping/arg order stuff?
- deleted 3y ago
  [deleted]
- eddythompson80 3y ago
  Yeah I’d think so too. FP languages like Haskell or F# has partial application as part of the language itself and you get it for free by just ordering the parameters that way.
gorgoiler 3y ago
Partial application makes sense to me as a useful computer science concept. Reasoning about functions when they always have 1-arity makes proofs possible. In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites: def serialize(fn, data, path): … yamlize = partial( serialize, yaml.dump ) jsonize = partial( serialize, json.dumps ) Presumably some of these people wake up in a cold sweat about the shame of typing “partial(serialize, …)” twice and do this: def serialize(fn, data, path): … a = lambda f: partial(serialize, f) yamlize = a(yaml.dump) jsonize = a(json.dumps) A good example of Don’t Repeat Yourself mutating into Never Repeat Yourself with ill effect, because the developer has self flagellated so much that the following code is deemed to have too much repetition in it: def write(data, path): … def write_yaml(data, path): write(yaml.dump(data), path) def write_json(data, path): write(json.dumps(data), path)

RedNifre 3y ago

As an illustration, I wrote a Sokoban game in that style (no mutation, no side effects, partial application everywhere). See https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game.js https://github.com/Michael-Zinn/fpsokobanjs/blob/master/game...