4 ms·

clicked on the link hoping it would explain why I might need to use currying.

kevincennis 11y ago
Yeah, sorry about that. I realized afterwards that a better title would probably have been "Writing a Curry Function in JavaScript".
bpicolo 11y ago
One example is it would allow you to pass arguments to callbacks other than those passed by whoever is using the callback (my example because it's the relevant part I use most frequently) There are infinite examples for this sort of thing in real development scenarioes
- Zalastax 11y ago
  In what way is it better than partial() from rambda or underscore? I have tried to see the potential in currying but gave up when I couldn't create a function with no parameters without calling it.
  - amalcon 11y ago
    It isn't better; it's the same thing less a few minor details. _.partial is a from of currying. It's just a matter of which syntax you prefer.
  - bpicolo 11y ago
    Why did you think you needed it in the case where you had a function that didn't need parameters? That sort of relinquishes the point of currying. (Should just be passing the function itself)
    - Zalastax 11y ago
      I had a function taking parameters and wanted a function without parameters. Using this style the function would be called immediately when all parameters are supplied, instead of in the callback as I intended.
      - bpicolo 11y ago
        Ahh, I see what you meant. That should work with a correct currying implementation for sure
braythwayt 11y ago
It’s often the case that writing a bit of infrastructure for something is a valuable exercise in and of itself. So we can debate how often you’d need to curry a function, but I feel safe suggesting that writing your own curry function (or reading along with an essay that does the same with lively interest) is valuable. Same with things like classes and mixins, there is now syntactic sugar for such things, but it’s always a good thing to have written your own MakeClass function at least once.
- kevincennis 11y ago
  OP here. That was kind of my intent (learning exercise rather than super practical real-world technique) -- but I'll admit I probably could have picked a better title.
  - braythwayt 11y ago
    Well, I liked it, and I personally don’t mind the title. It’s about currying and JavaScript, and it’s interesting, so that meets my (possibly low) bar for upboating.
hvs 11y ago
Ramdajs links to an old article that explains it pretty well: https://web.archive.org/web/20140714014530/http://hughfdjackson.com/javascript/why-curry-helps https://web.archive.org/web/20140714014530/http://hughfdjack... Ramdajs: http://ramdajs.com/0.16/index.html http://ramdajs.com/0.16/index.html
- nothrabannosir 11y ago
  Careful: objects.map(get('id')) and poof there goes your type safety. Optional typing (flow and TS) is making inroads into JS. If you want to bet on them (or any other JS inspecting tools), make sure you use this: objects.map(function (x) { return x.id; }); Or, in ES6 or TypeScript: objects.map(x => x.id) This helps computers understand your code.
  - chrisseaton 11y ago
    Can these typing algorithms not use the same transformation themselves to make sense of a call to get? I know there's a string there but it's literal.
    - nothrabannosir 11y ago
      Absolutely! If enough people do this, the tooling might eventually adapt. However, it's the kind of bet I wouldn't go long on. Today, TS automatically (and correctly) infers the type of objs.map(x => x.foo). I suppose the same holds true for flow. This is not hypothetical; try this in http://www.typescriptlang.org/Playground http://www.typescriptlang.org/Playground var objects = [ { id: 1, name: "Foo" }, { id: 2, name: "Bar" } ]; var look_at_my_type = objects.map(x => x.id); Note; this is 100% JS, just passed through a TS compiler. Check the type of look_at_my_type (e.g. start typing its name at the bottom, see what the popover says): number[]. Replace it by get('id') (with definition function get(name: string) { return x => x[name]; }), and the type becomes any[].

Yeah, sorry about that. I realized afterwards that a better title would probably have been "Writing a Curry Function in JavaScript".

bpicolo 11y ago

One example is it would allow you to pass arguments to callbacks other than those passed by whoever is using the callback (my example because it's the relevant part I use most frequently) There are infinite examples for this sort of thing in real development scenarioes

Zalastax 11y ago
In what way is it better than partial() from rambda or underscore? I have tried to see the potential in currying but gave up when I couldn't create a function with no parameters without calling it.
- amalcon 11y ago
  It isn't better; it's the same thing less a few minor details. _.partial is a from of currying. It's just a matter of which syntax you prefer.
- bpicolo 11y ago
  Why did you think you needed it in the case where you had a function that didn't need parameters? That sort of relinquishes the point of currying. (Should just be passing the function itself)
  - Zalastax 11y ago
    I had a function taking parameters and wanted a function without parameters. Using this style the function would be called immediately when all parameters are supplied, instead of in the callback as I intended.
    - bpicolo 11y ago
      Ahh, I see what you meant. That should work with a correct currying implementation for sure

braythwayt 11y ago

It’s often the case that writing a bit of infrastructure for something is a valuable exercise in and of itself. So we can debate how often you’d need to curry a function, but I feel safe suggesting that writing your own curry function (or reading along with an essay that does the same with lively interest) is valuable. Same with things like classes and mixins, there is now syntactic sugar for such things, but it’s always a good thing to have written your own MakeClass function at least once.

kevincennis 11y ago
OP here. That was kind of my intent (learning exercise rather than super practical real-world technique) -- but I'll admit I probably could have picked a better title.
- braythwayt 11y ago
  Well, I liked it, and I personally don’t mind the title. It’s about currying and JavaScript, and it’s interesting, so that meets my (possibly low) bar for upboating.

hvs 11y ago

Ramdajs links to an old article that explains it pretty well: https://web.archive.org/web/20140714014530/http://hughfdjackson.com/javascript/why-curry-helps https://web.archive.org/web/20140714014530/http://hughfdjack... Ramdajs: http://ramdajs.com/0.16/index.html http://ramdajs.com/0.16/index.html

nothrabannosir 11y ago
Careful: objects.map(get('id')) and poof there goes your type safety. Optional typing (flow and TS) is making inroads into JS. If you want to bet on them (or any other JS inspecting tools), make sure you use this: objects.map(function (x) { return x.id; }); Or, in ES6 or TypeScript: objects.map(x => x.id) This helps computers understand your code.
- chrisseaton 11y ago
  Can these typing algorithms not use the same transformation themselves to make sense of a call to get? I know there's a string there but it's literal.
  - nothrabannosir 11y ago
    Absolutely! If enough people do this, the tooling might eventually adapt. However, it's the kind of bet I wouldn't go long on. Today, TS automatically (and correctly) infers the type of objs.map(x => x.foo). I suppose the same holds true for flow. This is not hypothetical; try this in http://www.typescriptlang.org/Playground http://www.typescriptlang.org/Playground var objects = [ { id: 1, name: "Foo" }, { id: 2, name: "Bar" } ]; var look_at_my_type = objects.map(x => x.id); Note; this is 100% JS, just passed through a TS compiler. Check the type of look_at_my_type (e.g. start typing its name at the bottom, see what the popover says): number[]. Replace it by get('id') (with definition function get(name: string) { return x => x[name]; }), and the type becomes any[].