Functional JavaScript, Part 3: apply, call, and the arguments object

I find most JS written functionally (at least if it's done the right way) to be a lot easier to follow if you think of each functional "step" in the chain like columns in a spreadsheet. E.g. when I see something like _(array).filter(...).map(...).reject(...).reduce() I like to think of taking a value and following it the way you would across a spreadsheet and think of filter, map and reject as "columns". I don't know if that will help, but it does for me.

Yes, it's very popular with JS to make code more modular. Remember that, although JavaScript is a object-oriented language, it isn't a class-based language - it's a prototype-based language.

The best way to grasp the idea is by following various code examples (and how and why they were implemented that way). Also, I found Douglas Crockford's video presentations on JS _extremely_ helpful. I have a list of them here:

https://www.zeitgeist.se/2014/03/26/list-of-helpful-javascri...

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

I think so. It takes a while for it to `click`, but when it does you'll really start to enjoy it.

Having read the book, I can definitely recommend it. Along with the book, Braithwaite created [allonge.es][1], a functional js library which follows much more closely how I would create a FP utility library in JS (versus, something like lo-dash or underscore).

  [1]: https://github.com/raganwald/allong.es

From someone that already writes functional Javascript, I really liked the series. I learned from reading MDN, and this is a lot more to-the-point. Great job!

Side note: this is the first .pro domain I've seen so far.

I found your section on converting prototype methods into utility functions really interesting, I found myself doing the same thing a few days ago. One suggestion for your 'demethodize' function is to replace the prototype methods you use with purely functional versions (AKA replace [].slice and fn.apply). It seems kind of funky to have a function dedicated to demethodizing prototype methods that makes use of prototype methods!