If I'm writing a function where there isn't an obvious order for the arguments, I chose the order such that Currying is most useful, even if the language I'm writing in doesn't support Curried functions/partial function application. You never know when someone will port your code or create cross-language bindings.<p>For instance, my company writes a lot of code in a proprietary language and the other day I was writing a function to generate random strings, given a length and an "alphabet" string from which to choose characters.<p>I chose the ordering:<p><pre><code> randomString alphabet length = ...
</code></pre>
so that if partial function application were added to the language, one could simply write the functions randomHex and randomBase32 as:<p><pre><code> randomHex = randomString "0123456789ABCDEF"
randomBase32 = randomString "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"
</code></pre>
The alternative ordering would allow me to easily write functions that generate fixed length strings and take their alphabets as inputs:<p><pre><code> random10Char = randomString 10
random4Char = randomString 4
</code></pre>
This ordering is much less useful in general, so I chose to make the alphabet the first parameter.<p>On a side note, our language also has some time series extensions for dataflow programming. There's an API for efficiently adding new data flows based on something similar to template specialization, but the API is unwieldy and the source of much confusion. So, I wrote a wrapper API that uses reflection to expose the same functionality as partial function application / Curried functions over time series.
<i>Currying is the process of turning a function that expects multiple parameters into one that, when supplied fewer parameters, returns a new function that awaits the remaining ones.</i><p>I think this, along with the whole article, is the best explanation of currying I've seen on the whole damn internet.
Is the final code equivalent to:<p><pre><code> var getIncompleteTaskSummaries = function(membername) {
return fetchData().then(function(data) {
var incompleteTasks = [];
for (i = 0; i < data.tasks.length; ++i) {
var task = data.tasks[i];
if (task.username == membername && !task.complete) {
incompleteTasks.push({id: task.id, dueDate: task.dueDate, title: task.title, priority: task.priority});
}
}
incompleteTasks.sort(function(a, b) {
return a.getTime() - b.getTime();
});
return incompleteTasks;
});
}
</code></pre>
?<p>Apologies if that's wrong, i barely know JavaScript.<p>That code is not so great, and a bit '90s, but it's not appalling. The horrifically verbose non-currying code in the article isn't something i see any need to write. It looks like an outrageous strawman to me.<p>My code here could definitely improved with some functional idioms for the looping, picking, and sorting, but i wouldn't reach for currying here.
Currying can be hard to spot if you're not used to it. Especially in a language with inferred or dynamic type, it's not obvious that the var contains a function, not a result object.<p>var result = somefunc(a,b) // object
var otherResult = somefunc(a) // function<p>It gets even more confusing if overloading of function names for different parameters or different number of parameters is allowed.<p>So elegant: maybe. Readable: no. Depends on the programming language.
"Ok, here we go. Does code like this look at all familiar?"<p>No, because I use Array.prototype.filter(), Array.prototype.map(), and Array.prototype.reduce() to accomplish these things...
Basic point free style as described in the article is alright in javascript.<p>Extreme point free style does not work in javascript, AT ALL!!!! Two reasons:<p>1) Find the bug: the table sort is glitchy. Is the bug in this suspicious line, or somewhere else? (Real line of code in a codebase I inherited, and yes there is a bug in it)<p><pre><code> var sorted = rows.sort(_.unsplat(_.pipeline(
_.partial(_.map, _, accessor),
_.splat(comparator))));
</code></pre>
2) I use React, so I can get away with a lot of really functional stuff since React is well suited for functional javascript. React is a great functional abstraction, but under the abstraction is imperative code. Imperative code means you need a debugger. When you write in a point free style, there's nowhere to place a breakpoint!
I'm generally a fan of currying, but specifically when used with javascript, I think it can be problematic. The default behaviour of any function when called with fewer arguments than specified is to set named arguments to undefined. Meaning, functions in javascript always take any number of arguments and changing that default behaviour is confusing. There is also the matter of the "this" parameter.<p>I think that using the .bind() method on functions is the right approach. It will lead to less surprising behaviour in the context of javascript.
The "curried" code seems less readable and maintainable than the original code. Is this like dependency injection where I have to make my code harder to read and maintain to satisfy some technical definition of "loosely" couple?
I have no experience neither with JS nor with functional programming, but know Lambda calculus and currying from Discrete math courses.<p>As Currying and functional programming a popular thing now,
I was thinking what my current codebase would look like in C# if I were writing code in a more functional way.<p>So, obviously C# isn't a functional languageat all but using Func<T>, and maybe some delegates would enable this easily.<p>I'm not sure this would turn my code to more elegant or readable.<p>What would I benefit from ?
Note that currying is not necessary for partial application, here is partial application implemented in C++14: <a href="http://coliru.stacked-crooked.com/a/bed4a4fdd6e856b0" rel="nofollow">http://coliru.stacked-crooked.com/a/bed4a4fdd6e856b0</a><p>However, I find lambdas with the extra parameters repeated more readable than partial application.
I'm probably missing something, but why not just do...?<p><pre><code> var jp = function(last){
return formatNames2('John', 'Paul', last);
}</code></pre>