I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
I don't really like currying, but that might be because I've never used it beyond watching people's explanations. I can't think of a use case which couldn't be done in a simpler, more readable way.
Front end developer specialising in JavaScript and React. Experienced in all aspects of modern front end development. Passionate about making accessible, secure and performant software.
Currying on its own is simply a way to do partial application. Nothing more, nothing less. (Unless you subscribe to the fact that your code is easier to prove mathematically if your functions only accept one argument. But I've never had my code mathematically proven in my professional work.)
For example:
import{multiply}from'somewhere';// with curryingconstdouble1=multiply(2);// partial application without curryingconstdouble2=(number)=>multiply(number,2);// inline is shortest because you don't have to importconstdouble3=(number)=>number*2;
As you can see, the curried implementation is slightly cleaner and shorter if you need to do partial application (fix arguments on an already defined function). For complicated functions, you need to do partial application. You can't just redefine them inline every time you need them.
But as you can see, the benefit is small.
But, in programs written in a functional programming style, we do this a lot, so the little cleanliness of currying adds up.
For example:
// with curryingconstoperation=compose(baz(7),bar(5),foo(2));// with normal partial applicationconstoperation=compose((number)=>baz(7,number),(number)=>bar(5,number),(number)=>foo(2,number));// with imperative codefunctionoperation(number){constresult1=foo(2,number);constresult2=bar(5,result1);constresult3=baz(7,result2);returnresult3;}
So yeah, small benefit overall, but can make some things cleaner if you're used to the syntax.
Hope this is somewhat useful, even if it wasn't asked for :).
I don't really like currying, but that might be because I've never used it beyond watching people's explanations. I can't think of a use case which couldn't be done in a simpler, more readable way.
I felt exactly the same.. but this post changed my mind, some great explanations here βΊοΈβΊοΈ
Currying on its own is simply a way to do partial application. Nothing more, nothing less. (Unless you subscribe to the fact that your code is easier to prove mathematically if your functions only accept one argument. But I've never had my code mathematically proven in my professional work.)
For example:
As you can see, the curried implementation is slightly cleaner and shorter if you need to do partial application (fix arguments on an already defined function). For complicated functions, you need to do partial application. You can't just redefine them inline every time you need them.
But as you can see, the benefit is small.
But, in programs written in a functional programming style, we do this a lot, so the little cleanliness of currying adds up.
For example:
So yeah, small benefit overall, but can make some things cleaner if you're used to the syntax.
Hope this is somewhat useful, even if it wasn't asked for :).
Wow thanks! Great example and clear explanation, really useful βΊοΈ