An imperative programming style is categorized by its exquisite (and often infuriating) attention to the details of algorithm implementation. Further, imperative programs are often built around the direct manipulation and inspection of program state. For example, imagine that you’d like to write a program to build a lyric sheet for the song “99 Bottles of Beer.” The most direct way to describe the requirements of this program are as such:

As it turns out, this specification has a fairly straightforward imperative implementation in JavaScript, as shown here:

var lyrics = [];

for (var bottles = 99; bottles > 0; bottles--) {
  lyrics.push(bottles + " bottles of beer on the wall");
  lyrics.push(bottles + " bottles of beer");
  lyrics.push("Take one down, pass it around");

  if (bottles > 1) {
    lyrics.push((bottles - 1) + " bottles of beer on the wall.");
  }
  else {
    lyrics.push("No more bottles of beer on the wall!");
  }
}

This imperative version, while somewhat contrived, is emblematic of an imperative programming style. That is, the implementation describes a “99 Bottles of Beer” program and exactly a “99 Bottles of Beer” program. Because imperative code operates at such a precise level of detail, they are often one-shot implementations or at best, difficult to reuse. Further, imperative languages are often restricted to a level of detail that is good for their compilers rather than for their programmers (Sokolowski 1991).

By comparison, a more functional approach to this same problem might look as follows:

function lyricSegment(n) {
  return _.chain([])
    .push(n + " bottles of beer on the wall")
    .push(n + " bottles of beer")
    .push("Take one down, pass it around")
    .tap(function(lyrics) {
           if (n > 1)
             lyrics.push((n - 1) + " bottles of beer on the wall.");
           else
             lyrics.push("No more bottles of beer on the wall!");
         })
    .value();
}

The lyricSegment function does very little on its own—in fact, it only generates the lyrics for a single verse of the song for a given number:

lyricSegment(9);

//=> ["9 bottles of beer on the wall",
//    "9 bottles of beer",
//    "Take one down, pass it around",
//    "8 bottles of beer on the wall."]

Functional programming is about pulling programs apart and reassembling them from the same parts, abstracted behind function boundaries. Thinking in this way, you can imagine that the lyricSegment function is the part of the “99 Bottles” program that abstracts lyric generation. Therefore, the part of the program that abstracts the assembly of the verse segments into a song is as follows:

function song(start, end, lyricGen) {
  return _.reduce(_.range(start,end,-1),
    function(acc,n) {
      return acc.concat(lyricGen(n));
    }, []);
}

And using it is as simple as:

song(99, 0, lyricSegment);

//=> ["99 bottles of beer on the wall",
//    ...
//    "No more bottles of beer on the wall!"]

Abstracting in this way allows you to separate out domain logic (i.e., the generation of a lyrical verse) from the generic verse assembly machinery. If you were so inclined, you could pass different functions like germanLyricSegment or agreementLyricSegment into song to generate a different lyric sheet altogether. Throughout this book, I’ll use this technique, and explain it in greater depth along the way.

JavaScript is very similar to Java or C# in that its constructor functions are classes (at least at the level of implementation details), but the method of use is at a lower level. Whereas every instance in a Java program is generated from a class serving as its template, JavaScript instances use existing objects to serve as prototypes for specialized instances.^[27] Object specialization, together with a built-in dispatch logic that routes calls down what’s called a prototype chain, is far more low-level than class-oriented programming, but is extremely elegant and powerful. I will talk about exploiting JavaScript’s prototype chain later in Chapter 9.

For now, how this relates to functional programming is that functions can also exist as values of object fields, and Underscore itself is the perfect illustration:

_.each;

//=> function (array, n, guard) {
//    ...
//   }

This is great and beautiful, right? Well…not exactly. You see, because JavaScript is oriented around objects, it must have a semantics for self-references. As it turns out, its self-reference semantics conflict with the notion of functional programming. Observe the following:

var a = {name: "a", fun: function () { return this; }};

a.fun();
//=> {name: "a", fun: ...};

You’ll notice that the self-reference this returned from the embedded fun function returns the object a itself. This is probably what you would expect. However, observe the following:

var bFunc = function () { return this };
var b = {name: "b", fun: bFunc};

b.fun();
//=> some global object, probably Window

Well, this is surprising. You see, when a function is created outside of the context of an object instance, its this reference points to the global object. Therefore, when I later bound bFunc to the field b.fun, its reference was never updated to b itself. In most programming languages offering both functional and object-oriented styles, a trade-off is made in the way that self-reference is handled. JavaScript has its approach while Python has a different approach and Scala has a different approach still. Throughout this book, you’ll notice a fundamental tension between an object-oriented style and a functional style, but Underscore provides some tools to relieve, if not eliminate, this tension. This will be covered in greater depth later, but for now keep in mind that when I use the word “function” I mean a function that exists on its own and when I use “method” I mean a function created in the context of an object.

Related to prototype-based object-oriented programming are the facilities provided by JavaScript supporting metaprogramming. Many programming languages support metaprogramming, but rarely do they provide the level of power offered by JavaScript. A good definition of metaprogramming goes something like this: programming occurs when you write code to do something and metaprogramming occurs when you write code that changes the way that something is interpreted. Let’s take a look at an example of metaprogramming so that you can better understand.

In the case of JavaScript, the dynamic nature of the this reference can be exploited to perform a bit of metaprogramming. For example, observe the following constructor function:

function Point2D(x, y) {
  this._x = x;
  this._y = y;
}

When used with new, the Point2D function gives a new object instance with the proper fields set as you might expect:

new Point2D(0, 1);

//=> {_x: 0, _y: 1}

However, the Function.call method can be used to metaprogram a derivation of the Point2D constructor’s behavior for a new Point3D type:

function Point3D(x, y, z) {
  Point2D.call(this, x, y);
  this._z = z;
}

And creating a new instance works like a champ:

new Point3D(10, -1, 100);

//=> {_x: 10, _y: -1, _z: 100}

Nowhere did Point3D explicitly set the values for this._x and this._y, but by dynamically binding the this reference in a call to Point2D it became possible to change the target of its property creation code.

I will not go too deeply into JavaScript metaprogramming in this book because it’s orthogonal to functional programming, but I’ll take advantage of it occassionally throughout this book.^[28]

You’ve already seen the _.reduce function, but I failed to mention its sibling _.reduceRight. The two functions operate in much the same way, except that _.reduce works from left to right, whereas _.reduceRight works from right to left. Observe the differences:

var nums = [100,2,25];

function div(x,y) { return x/y };

_.reduce(nums, div);
//=> 2

_.reduceRight(nums, div);
//=> 0.125

The work of _.reduce is similar to (100/2) / 25 while _.reduceRight is (25/2) / 100. If the function supplied to the reduce siblings is associative, then they wind up returning the same values, but otherwise the difference in ordering can prove useful. Many common functions can be created using _.reduceRight. Here are a couple more examples:

function allOf(/* funs */) {
  return _.reduceRight(arguments, function(truth, f) {
    return truth && f();
  }, true);
}

function anyOf(/* funs */) {
  return _.reduceRight(arguments, function(truth, f) {
    return truth || f();
  }, false);
}

Example usages of allOf and anyOf are as follows:

function T() { return true }
function F() { return false }

allOf();
//=> true
allOf(T, T);
//=> true
allOf(T, T, T , T , F);
//=> false

anyOf(T, T, F);
//=> true
anyOf(F, F, F, F);
//=> false
anyOf();
//=> false

The _.reduceRight function has further advantages in languages providing lazy evaluation, but since JavaScript is not such a language, evaluation order is the key factor (Bird 1988).^[29]

The find function is fairly straightforward; it takes a collection and a predicate and returns the first element for which the predicate returns true. An example of find is as follows:

_.find(['a', 'b', 3, 'd'], _.isNumber);
//=> 3

Notice the use of the built-in function _.isNumber as the predicate function. Underscore comes with numerous predicates ready for use, including _.isEqual, _.isEmpty, _.isElement, _.isArray, _.isObject, _.isArguments, _.isFunction, _.isString, _.isNumber, _.isFinite, _.isBoolean, _.isDate, _.isRegExp, _.isNaN, _.isNull, and _.isUndefined. I will use some or all of them over the course of this book.

Underscore’s _.reject is essentially the opposite of _.filter; it takes a predicate and returns a collection of values that excludes values for which the predicate returned true. For example:

_.reject(['a', 'b', 3, 'd'], _.isNumber);
//=> ['a', 'b', 'd']

This is the same as reversing the truthiness of the predicate to _.filter. In fact, a simple function called complement would perform just such a task:^[30]

function complement(pred) {
  return function() {
    return !pred.apply(null, _.toArray(arguments));
  };
}

The complement function takes a predicate and returns a function that reverses the sense of the result of said predicate. It can then be used with _.filter to achieve the same effect as _.reject:

_.filter(['a', 'b', 3, 'd'], complement(_.isNumber));
//=> ['a', 'b', 'd']

The complement function is an example of a higher-order function. Although I touched briefly on what that means earlier, I will defer a deeper discussion until Chapter 3.

The _.all function takes a collection and a predicate, and returns true if all of the elements within return true on the predicate check. For example:

_.all([1, 2, 3, 4], _.isNumber);
//=> true

Of course, if any of the elements fail the predicate test, then _.all returns false.

The _.any function takes a collection and a predicate, and returns true if any of the elements within return true on the predicate check. For example:

_.any([1, 2, 'c', 4], _.isString);
//=> true

Of course, if all of the elements fail the predicate test, then _.any returns false.

The last three applicative functions that I’ll discuss are related, in that they all perform some action based on the result of a given criteria function. The first of the three, _.sortBy, takes a collection and a function, and returns a sorted collection based on the criteria determined by the passed function. For example:

var people = [{name: "Rick", age: 30}, {name: "Jaka", age: 24}];

_.sortBy(people, function(p) { return p.age });

//=> [{name: "Jaka", age: 24}, {name: "Rick", age: 30}]

The _.groupBy function takes a collection and a criteria function, and returns an object where the keys are the criteria points returned by the function, and their associated values are the elements that matched. For example:

var albums = [{title: "Sabbath Bloody Sabbath", genre: "Metal"},
              {title: "Scientist", genre: "Dub"},
              {title: "Undertow", genre: "Metal"}];

_.groupBy(albums, function(a) { return a.genre });

//=> {Metal:[{title:"Sabbath Bloody Sabbath", genre:"Metal"},
//           {title:"Undertow", genre:"Metal"}],
//    Dub:  [{title:"Scientist", genre:"Dub"}]}

The _.groupBy function is extremely handy, and will show up numerous times throughout the course of this book.

The final applicative function I’ll discuss is called _.countBy. This function works similarly to _.groupBy, except that it returns an object with keys of the match criteria associated with its count, as shown in the following:

_.countBy(albums, function(a) { return a.genre });

//=> {Metal: 2, Dub: 1}

That wraps up this discussion of applicative functional programming. I started with the most common case of a functional style that you’re likely to encounter in JavaScript code, so that you have some background knowledge before venturing deeper into the wilderness. Up next, I’ll cover one more common topic in JavaScript code: closures.