Imperative programming is concerned with how

Functional programming is concerned with what

• First-class Functions
• Higher-order Functions
• Recursion
• Pure functions
• Currying & Partial Application

• Lazy Evaluation
• Types & Data Structures
• Category Theory

• Are values
• Have no restriction on their use
• Enable the use of callback functions in JavaScript

var fn = function () {
  return 2
}

Functions that operate on other functions are higher-order functions

var succ = function (x) {
  return x + 1
}

var arr = [1, 2, 3, 4]

arr.map(succ)

Here, Array.prototype.map is the higher-order function

Functions that return functions are also higher-order functions

function adder (n) {
  return function (x) {
    return n + x
  }
}

var add1 = adder(1)

adder is a higher-order function

Functions without side-effects

var succ = (x) => x + 1

console.log(succ(succ(1)))

// could be optimised away by a compiler, e.g.:

console.log(3)

Functions that call themselves

function fibonacci (n) {
  switch (n) {
    case 0:
    case 1:
      return 1
    default: 
      return fibonacci(n - 1) + fibonacci(n - 2)
  }
}

The infamous Function.prototype.bind in JavaScript

function add (x, y) {
  return x + y
}

var add1 = add.bind(add, 1)

add1(3) // = 4

After ES6 introduced arrow functions, partial application has become more popular

var add = x => y => x + y

Related to partial application, but more implicit and general

Translates 1 function of arity n to n functions of arity 1

function volume (w, d, h) {
  return w * d * h
}

var vol = curry(volume)
vol(10)(20)(30)
// is strictly equivalent to
volume(10, 20, 30)

In order to make currying (and partial application) easier to use, move the most important argument to a function to the end:

var badMap = (arr, fn) => arr.map(fn)
var goodMap = (fn, arr) => arr.map(fn)
var curriedBadMap = curry(badmap)
var curriedGoodMap = curry(goodMap)

var goodDoubleArray = goodMap(x => x * 2)
var badDoubleArray = badMap(_, x => x * 2)

The bad version requires the curry function to support a magic placeholder argument and doesn't look as clean.

Currying is not automatic in JavaScript, as in other languages

External tools aren't (so far) able to statically analyse curried functions

Solution: Don't expose curried functions Instead, write functions as if currying were automatic

If consumers want to curry, they can. If they don't, their editor or language server will show them the arguments

Creating functions from other functions

Usually provided by compose (right-to-left) and pipe (left-to-right)

A very simple definition of compose for only two functions would look like this

function compose (f, g) {
  return function (...args) {
    return f(g(...args))
  }
}

What about pipe?

pipe does the same thing, but runs the functions the other way around

pipe(f, g) is the same as compose(g, f)

With currying and higher-order functions, we (often) don't need to declare function arguments

var modulo = a => b => b % a
var eq = a => b => a === b

var isEven = x => eq(0)(modulo(2)(x))
var isEvenPointFree = compose(eq(0), modulo(2))

• Mostly adequate guide to FP (in javascript)
• Ramda, a general-purpose FP library
• Sanctuary, a JavaScript library for Haskellers