The Functional Paradigm

Core Tenets

  1. (Mostly) everything is functions all the way down. If it's more than a unary function i.e. (a, b) => a + b, they should be curried.

    Good functions are pure functions pure functions are deterministic, meaning that with the same inputs they return the same outputs, they have no side-effects, meaning they do not make change external to the body of the function and they are referentially transparent so if you know the inputs you can compare them transparently with their outputs.

    When choosing an order for parameters in a curried function, in general it makes most sense to order them by order-of-likely availability, with the last parameter as the one which is the primary subject of the function going into the pipe.

  2. Prefer function composition and transformation via higher-order functions over inline function complexity. (See more examples in the glossary)

  3. Avoid mutating or destructing data. Instead, make a copy of the data, and do whatever you want to that. This prevents hard-to-track errors and adheres to creating no side-effects.

  4. Prefer map over other loops. Discrete iterable values are pure. For instance, a for loop which conditionally pushes into an array, especially an array (potentially accessible from a shared context which could also then mutate it).

  5. Functions should cleave towards being as generic as possible. This aids both readability and logical reasoning.

  6. There's a form of FP which is called tacit or point-free which attempts to eschew defining parameters where possible, instead relying upon explicit function arity. This is not mandatory to be writing functional code. However, as it is often less code to write and helps reinforce the idea that everything is a function (often a composed one). An example of a tacit function:

    pipe(slice(0, 3), toUpper)

(For a lot more, you could check out our references page or see the wiki page on category theory)

FP Reading

Explicit Function Arity
FP Quiz - Why doesn't parseInt behave as we expect?
Identity Closure
An identity closure refers to a function which calls another function and returns the result, usually doing no intermediary translation.
Using Side-Effects to Inspect Data
How can we take a look at data in a composed pipeline?
Problematic imperative code
As we're trying to move towards cleaner and simpler code through FP, how can we identify code that needs to be cleaned up in transition?
See this page on Github
Built with 💛 by Open Sorcerers
Created with Gatsby using the 😎 foresight starter