Yes and no.
Some of this is that JavaScript is just not very well equipped to do functional programming. For instance, the nesting of functions in JavaScript is not only verbose to write, it also introduces a lot of noise in the code.
One pretty simple/obvious setback for JavaScript is that declaring an anonymous function (or a lambda) entails quite a few characters. In ES6, [this will change with the introduction of "Arrow Functions"][2], but that's not going to be a cure-all by any means.
Languages geared more towards the functional edge will handle things like curried higher order functions almost without you realizing it. For instance, taking an excerpt from my next post in the series (still unpublished):
var uncurried = function (a, b, c) {
// do something with a, b, and c
};
var curried = function(a) {
return function (b) {
return function (c) {
// do something with a, b, and c
};
};
};
There we have two ternary functions (3 arguments), but the first one is uncurried (how you would expect it in javascript), and the second one is manually written in a curried fashion.
Some programming languages, such as Haskell and OCaml, have function currying built into the language. What that means is that, technically, every function is a function of one argument, and one argument only. Syntactically, however, they may make this restriction almost unnoticable.
For instance, in OCaml, one could write the two functions above like:
let uncurried = fun a b c ->
// (* do something with a, b, c *)
let curried = fun a ->
fun b ->
fun c ->
// (* do something with a, b, c *)
The difference, however, is that in OCaml these are
exactly the same thing. In OCaml, no functions have multiple arguments. However, invoking curried functions syntactically looks the same as what one would expect invoking a function with multiple arguments would be. To call the functions above we would write:
uncurried foo bar baz
curried foo bar baz
Whereas in JavaScript, we have the obvious difference:
uncurried(foo, bar, baz);
curried(foo)(bar)(baz);
Many would argue that the readability of the former is much better than the latter.
---
Anyway, what I am trying to build up to in this series is building a set of tools to make writing code like this a little more fluid in JavaScript than native JavaScript would allow.
This goes back to my example in [Part 1][1], where I show an underscore example:
var firstTwoLetters = function(words){
return _.map(words, function(word){
return _.first(word, 2);
});
};
Which, the
exact same thing can be represented "my way" with:
var firstTwoLetters = map(first(2));
I would argue that this is much more readable, and perhaps you would agree?
[1]: http://tech.pro/tutorial/1953/functional-javascript-part-1-introduction
[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions