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.

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.

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.

Ramdajs links to an old article that explains it pretty well:

https://web.archive.org/web/20140714014530/http://hughfdjack...

Ramdajs: http://ramdajs.com/0.16/index.html

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.

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.

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

    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".

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

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.

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)

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.

Ahh, I see what you meant. That should work with a correct currying implementation for sure

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.