Mo Closures and Currying
-
I mentioned to @jmaida I'd give another example of closures in the language that shall not be named (rhymes with GuavaScript). Closures can not only be used to fake OOP, as it were. They can also be applied to functional concepts. In functional programming, there's a concept called currying. And like anything in tech, it sounds way more complicated than it is.
const fooBar = function(foo) {
// this is a curried function, essentially a function returning a function
return function(bar) {
return foo + bar; // the whole deal with closures and foo should look familiar
};
};Let's get fancy now with some modern syntax.
// this is a curried arrow function, notice the double =>, it's a function returning another function
// foo is treated just the same as in the previous example
const fooBar = foo => bar => `${foo} and ${bar} sitting in a tree`;// these will print the outer and inner functions that was returned
console.log(fooBar, fooBar());// this will call the outer function and then the inner function
console.log(fooBar('sup')('dawg')); // outputs "sup and dawg sitting in a tree"So you're probably thinking, ok but that's whack. What the fudge do people use currying for? Two reasons actually. Let's say you got a function to call with the same parameters over and over again, and it just looks nasty. And nasty code is... well nasty. You can clean it up with a curry.
// using the example above
const supDawg = fooBar('sup')('dawg');// look ma, no params
console.log(supDawg); // outputs "sup and dawg sitting in a tree"Ok, so that's cool. But let's be real, it's not practical. A practical application of currying would be analogous to an abstract base class in OOP-land and how that helps with reuse. Also, kinda like how an abstract class is never supposed to be directly instantiated, the "abstract" logic should never be directly called outside the scope of the outer function. But, being functional, you get another benefit too.
// happily ganked this code snippet from SO
const doTheHardStuff = function(x) {
// the outer function is the abstract part, should make sense to dyslexics
// its calling doSomethingComputationallyExpensive, which shouldn't be directly called
const z = doSomethingComputationallyExpensive(x);return function (y) {
z + y;
}
}const finishTheJob = doTheHa
-
I mentioned to @jmaida I'd give another example of closures in the language that shall not be named (rhymes with GuavaScript). Closures can not only be used to fake OOP, as it were. They can also be applied to functional concepts. In functional programming, there's a concept called currying. And like anything in tech, it sounds way more complicated than it is.
const fooBar = function(foo) {
// this is a curried function, essentially a function returning a function
return function(bar) {
return foo + bar; // the whole deal with closures and foo should look familiar
};
};Let's get fancy now with some modern syntax.
// this is a curried arrow function, notice the double =>, it's a function returning another function
// foo is treated just the same as in the previous example
const fooBar = foo => bar => `${foo} and ${bar} sitting in a tree`;// these will print the outer and inner functions that was returned
console.log(fooBar, fooBar());// this will call the outer function and then the inner function
console.log(fooBar('sup')('dawg')); // outputs "sup and dawg sitting in a tree"So you're probably thinking, ok but that's whack. What the fudge do people use currying for? Two reasons actually. Let's say you got a function to call with the same parameters over and over again, and it just looks nasty. And nasty code is... well nasty. You can clean it up with a curry.
// using the example above
const supDawg = fooBar('sup')('dawg');// look ma, no params
console.log(supDawg); // outputs "sup and dawg sitting in a tree"Ok, so that's cool. But let's be real, it's not practical. A practical application of currying would be analogous to an abstract base class in OOP-land and how that helps with reuse. Also, kinda like how an abstract class is never supposed to be directly instantiated, the "abstract" logic should never be directly called outside the scope of the outer function. But, being functional, you get another benefit too.
// happily ganked this code snippet from SO
const doTheHardStuff = function(x) {
// the outer function is the abstract part, should make sense to dyslexics
// its calling doSomethingComputationallyExpensive, which shouldn't be directly called
const z = doSomethingComputationallyExpensive(x);return function (y) {
z + y;
}
}const finishTheJob = doTheHa
kys
-
kys
I realize this is a joke, but talking about CPU registers and protected memory may seem like a lot to a newbie. As a point of reference.
Jeremy Falcon
-
I realize this is a joke, but talking about CPU registers and protected memory may seem like a lot to a newbie. As a point of reference.
Jeremy Falcon
DNFTT. :) Spam and Abuse Watch[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I mentioned to @jmaida I'd give another example of closures in the language that shall not be named (rhymes with GuavaScript). Closures can not only be used to fake OOP, as it were. They can also be applied to functional concepts. In functional programming, there's a concept called currying. And like anything in tech, it sounds way more complicated than it is.
const fooBar = function(foo) {
// this is a curried function, essentially a function returning a function
return function(bar) {
return foo + bar; // the whole deal with closures and foo should look familiar
};
};Let's get fancy now with some modern syntax.
// this is a curried arrow function, notice the double =>, it's a function returning another function
// foo is treated just the same as in the previous example
const fooBar = foo => bar => `${foo} and ${bar} sitting in a tree`;// these will print the outer and inner functions that was returned
console.log(fooBar, fooBar());// this will call the outer function and then the inner function
console.log(fooBar('sup')('dawg')); // outputs "sup and dawg sitting in a tree"So you're probably thinking, ok but that's whack. What the fudge do people use currying for? Two reasons actually. Let's say you got a function to call with the same parameters over and over again, and it just looks nasty. And nasty code is... well nasty. You can clean it up with a curry.
// using the example above
const supDawg = fooBar('sup')('dawg');// look ma, no params
console.log(supDawg); // outputs "sup and dawg sitting in a tree"Ok, so that's cool. But let's be real, it's not practical. A practical application of currying would be analogous to an abstract base class in OOP-land and how that helps with reuse. Also, kinda like how an abstract class is never supposed to be directly instantiated, the "abstract" logic should never be directly called outside the scope of the outer function. But, being functional, you get another benefit too.
// happily ganked this code snippet from SO
const doTheHardStuff = function(x) {
// the outer function is the abstract part, should make sense to dyslexics
// its calling doSomethingComputationallyExpensive, which shouldn't be directly called
const z = doSomethingComputationallyExpensive(x);return function (y) {
z + y;
}
}const finishTheJob = doTheHa
There are rare times when I wish currying in C# was as simple as it is in F#. Code rant: Currying in C# with Oliver Sturm[^] Granted, a 2008 post.
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework -
There are rare times when I wish currying in C# was as simple as it is in F#. Code rant: Currying in C# with Oliver Sturm[^] Granted, a 2008 post.
Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity FrameworkThat's cool though, pulling it off in C#. Major nerd points awarded.
Jeremy Falcon
-
DNFTT. :) Spam and Abuse Watch[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I mentioned to @jmaida I'd give another example of closures in the language that shall not be named (rhymes with GuavaScript). Closures can not only be used to fake OOP, as it were. They can also be applied to functional concepts. In functional programming, there's a concept called currying. And like anything in tech, it sounds way more complicated than it is.
const fooBar = function(foo) {
// this is a curried function, essentially a function returning a function
return function(bar) {
return foo + bar; // the whole deal with closures and foo should look familiar
};
};Let's get fancy now with some modern syntax.
// this is a curried arrow function, notice the double =>, it's a function returning another function
// foo is treated just the same as in the previous example
const fooBar = foo => bar => `${foo} and ${bar} sitting in a tree`;// these will print the outer and inner functions that was returned
console.log(fooBar, fooBar());// this will call the outer function and then the inner function
console.log(fooBar('sup')('dawg')); // outputs "sup and dawg sitting in a tree"So you're probably thinking, ok but that's whack. What the fudge do people use currying for? Two reasons actually. Let's say you got a function to call with the same parameters over and over again, and it just looks nasty. And nasty code is... well nasty. You can clean it up with a curry.
// using the example above
const supDawg = fooBar('sup')('dawg');// look ma, no params
console.log(supDawg); // outputs "sup and dawg sitting in a tree"Ok, so that's cool. But let's be real, it's not practical. A practical application of currying would be analogous to an abstract base class in OOP-land and how that helps with reuse. Also, kinda like how an abstract class is never supposed to be directly instantiated, the "abstract" logic should never be directly called outside the scope of the outer function. But, being functional, you get another benefit too.
// happily ganked this code snippet from SO
const doTheHardStuff = function(x) {
// the outer function is the abstract part, should make sense to dyslexics
// its calling doSomethingComputationallyExpensive, which shouldn't be directly called
const z = doSomethingComputationallyExpensive(x);return function (y) {
z + y;
}
}const finishTheJob = doTheHa
Thank you. Much appreciated. A lot to chew on. BTW contrary to Richard's Demming's jab DNFTT. Smile | :) I am not trolling. I am honestly trying to learn concepts new to me.
"A little time, a little trouble, your better day" Badfinger
-
DNFTT. :) Spam and Abuse Watch[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Thank you. Much appreciated. A lot to chew on. BTW contrary to Richard's Demming's jab DNFTT. Smile | :) I am not trolling. I am honestly trying to learn concepts new to me.
"A little time, a little trouble, your better day" Badfinger
jmaida wrote:
contrary to Richard's Demming's jab DNFTT
You seem to be labouring under the misapprehension that I was referring to you. I was not. Follow the link in my message: there was a troll with the highly amusing username of "poopoopeepee0", whose since-deleted message Jeremy was replying to. When I posted my comment, you hadn't even replied to the thread. So unless that troll was a sock puppet account you had created, I don't understand your confusion. :confused: Edit: Unless you thought I was referring back to your comments in Marc's thread from yesterday[^]? Which I wasn't.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
jmaida wrote:
contrary to Richard's Demming's jab DNFTT
You seem to be labouring under the misapprehension that I was referring to you. I was not. Follow the link in my message: there was a troll with the highly amusing username of "poopoopeepee0", whose since-deleted message Jeremy was replying to. When I posted my comment, you hadn't even replied to the thread. So unless that troll was a sock puppet account you had created, I don't understand your confusion. :confused: Edit: Unless you thought I was referring back to your comments in Marc's thread from yesterday[^]? Which I wasn't.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Thank you. Much appreciated. A lot to chew on. BTW contrary to Richard's Demming's jab DNFTT. Smile | :) I am not trolling. I am honestly trying to learn concepts new to me.
"A little time, a little trouble, your better day" Badfinger
You’re totally welcome. Btw, Richard was referring to some posts that were deleted. Was a different dude he was talking about, promise.
Jeremy Falcon
-
Thank you. Much appreciated. A lot to chew on. BTW contrary to Richard's Demming's jab DNFTT. Smile | :) I am not trolling. I am honestly trying to learn concepts new to me.
"A little time, a little trouble, your better day" Badfinger
Also there a ton of functional concepts worth chatting about. Maybe it’s my C background but I love the functional paradigm more than OOP. It’s like the cool kid that nobody talks about.
Jeremy Falcon
-
Also there a ton of functional concepts worth chatting about. Maybe it’s my C background but I love the functional paradigm more than OOP. It’s like the cool kid that nobody talks about.
Jeremy Falcon
