DEV Community: Richard Tong

Practical Functional Programming in JavaScript - Side Effects and Purity

Richard Tong — Mon, 03 Aug 2020 18:00:13 +0000

Today we'll discuss two fundamental qualities of JavaScript functions and systems: side effects and purity. I also demonstrate an approach to organizing programs around these qualities with a couple of functions from my functional programming library, rubico.

A function is pure if it satisfies the following conditions:

Its return value is the same for the same arguments
Its evaluation has no side effects

A function's side effect is a modification of some kind of state beyond a function's control - for instance:

Changing the value of a variable;
Writing some data to disk;
Enabling or disabling a button in the User Interface.

Here are some more instances of side effects

reading data from a file
making a request to a REST API
writing to a database
reading from a database
logging out to console

Indeed, console.log is a side-effecting function.

// console.log(message string) -> undefined
console.log('hey') // undefined

In pure math terms, console.log takes a string and returns undefined, which isn't so useful. However, console.log is very useful in practice because of its side effect: logging any arguments you pass it out to the console. I like console.log because it only does one thing and does it well: log stuff out to the console. When the most straightforward solutions to real life challenges involve a mixture of side-effects and pure computations at a similar execution time, it's useful to have functions like console.log that have isolated, predictable behavior. My opinion is it's misguided to try to temporally separate side-effects and pure computations in JavaScript for the sake of mathematical purity - it's just not practical. Rather, my approach is to isolate side effects to simple functions like console.log.

I'll demonstrate with a function add10 with several different side effects. add10 is not pure.

let numCalls = 0

const add10 = number => {
  console.log('add10 called with', number)
  numCalls += 1
  console.log('add10 called', numCalls, 'times')
  return number + 10
}

add10(10) /*
add10 called with 10
add10 called 1 times
20
*/

add10 has the side effects of logging out to the console, mutating the variable numCalls, and logging out again. Both console.log statements have side effects because they use the function console.log, which has the side effect of logging out to the console. The statement numCalls += 1 also has a side effect because the variable numCalls is state beyond the control of the function.

By refactoring the console logs and the variable mutation to an outside function add10WithSideEffects, we can have a pure add10.

let numCalls = 0

const add10 = number => number + 10

const add10WithSideEffects = number => {
  console.log('add10 called with', 10)
  numCalls += 1
  console.log('add10 called', numCalls, 'times')
  return add10(10)
}

add10WithSideEffects(10) /*
add10 called with 10
add10 called 1 times
20
*/

Keep in mind that while add10 is now pure, all we've done is move our side effects outside the scope of add10 and into the more explicit add10WithSideEffects. Now we're being explicit about the side effects at least, but it's still a bit messy in my eyes. As far as vanilla JavaScript goes, this code is fine. However, I think we can get cleaner with my functional programming library, rubico.

The functions are simple enough at their core so that if you don't want to use a library, you can take these versions of the functions in vanilla JavaScript. Introducing: pipe and tap

/**
 * @name pipe
 *
 * @synopsis
 * pipe(funcs Array<function>)(value any) -> result any
 */
const pipe = funcs => function pipeline(value) {
  let result = value
  for (const func of funcs) result = func(result)
  return result
}

/**
 * @name tap
 *
 * @synopsis
 * tap(func function)(value any) -> value
 */
const tap = func => function tapping(value) {
  func(value)
  return value
}

pipe takes an array of functions and chains them all together, calling the next function with the previous function's output. We'll use pipe as a base foundation to organize our side effects.
tap takes a single function and makes it always return whatever input it was passed. When you use tap on a function, you're basically saying "don't care about the return from this function, just call the function with input and give me back my input". tap is great for functions responsible for a single side-effect like console.log. We'll use tap to separate our side-effects by function.

const logCalledWith = number => console.log('add10 called with', number)

let numCalls = 0

const incNumCalls = () => numCalls += 1

const logNumCalls = () => console.log('add10 called', numCalls, 'times')

const add10 = number => number + 10

const add10WithSideEffects = pipe([
  tap(logCalledWith),
  tap(incNumCalls),
  tap(logNumCalls),
  add10,
])

add10WithSideEffects(10) /*
add10 called with 10
add10 called 1 times
20
*/

We've isolated the console.log and variable mutation side effects to the edges of our code by defining them in their own functions. The final program is a composition of those side effecting functions and a pure function add10. To be clear, add10WithSideEffects is not pure; all we've done is move our side effects out to their own functions and, in a way, declare them with tap. The goal here is not to be pure for purity's sake, but to have clean, readable code with organized side-effects.

logCalledWith takes a number and logs 'add10 called with' number
incNumCalls takes nothing and increments the global variable numCalls
logNumCalls takes nothing and logs the global variable numCalls

All of these functions are singly responsible for what they do. When used with pipe and tap in add10WithSideEffects, the side effects of our program are clear.

Thanks for reading! You can find the rest of this series in the awesome resources section of rubico.

Photo credits:
https://www.pinterest.com/pin/213639576046186615/

Sources:
https://en.wikipedia.org/wiki/Pure_function
https://softwareengineering.stackexchange.com/questions/40297/what-is-a-side-effect

Practical Functional Programming in JavaScript - Error Handling

Richard Tong — Sat, 01 Aug 2020 17:56:55 +0000

Hello. You've arrived at an entire post about error handling.

Comic Credits: https://xkcd.com/2303/

Today we'll talk about Errors in JavaScript functional programming. Errors are about setting expectations, and bugs happen when expectations miss reality. Proper error handling (both throwing and catching) is key to writing code with fewer bugs. In this article, we will explore current and historical methods for JavaScript error handling and attempt to settle on a good general way with current JavaScript syntax to handle Errors. I will also plug a function from my library at the end (with good reason, of course).

Without further ado, let's see what is currently happening with errors in JavaScript functional programming

Feel free to click into these yourself, but I'll save you the trouble - all three articles say something along the lines of "stop throwing errors, instead use the Either monad".

Usually I don't think replacing a part of the language is a good way to go about things, unless the replacement offers something substantially better. Let's make our own judgment by exploring monads. What is a monad?

a monad is an abstraction that allows structuring programs generically while automating away boilerplate code needed by the program logic.

Moreover, monads have a spec. A monad is defined by

a type constructor - something with a prototype

function MyMonad(x) {...}

a type converter - a way to get a value into a monad

MyMonad.of = x => new MyMonad(x)

a combinator - a way to combine multiple instances of a monad

myMonad.chain(anotherMyMonad) -> combinedMyMonad

Now for Either. Here's a minimal Either monad implementation:

function Left(x) {
  this.value = x
}

function Right(x) {
  this.value = x
}

function Either(leftHandler, rightHandler, x) {
  return x.constructor === Left ? leftHandler(x.value) : rightHandler(x.value)
}

Here's how you would use the Either monad.

// parseJSON(s string) -> Either<Left<Error>, Right<Object>>
const parseJSON = s => {
  try {
    return new Right(JSON.parse(s))
  } catch (err) {
    return new Left(err)
  }
}

Either(
  err => console.error(err), // Left
  parsed => console.log(parsed), // Right
  parseJSON('{"a":1,"b":2,"c":3}'),
) // { a: 1, b: 2, c: 3 }

The way with the Either monad certainly looks pure, but is it really any better than a try catch block?

try {
  const parsed = JSON.parse('{"a":1,"b":2,"c":3}')
  console.log(parsed)
} catch (err) {
  console.error(err)
}

Directly above is a vanilla JavaScript try catch block that does everything the Either monad does in the previous example. The snippet above does not require a parseJSON function for Left and Right monads, and is generally more concise. I do not see the benefit of the Either monad when there is already try catch blocks and throw. My opinion is the Either monad doesn't pull enough weight versus regular JavaScript syntax for any serious use. However, I do like that the Either monad promotes a functional style.

There is a similar shortcircuiting pattern to the Either monad in asynchronous callback handlers.

function asyncFunc(userID, cb) {
  getUserByID(userID, (err, user) => {
    if (err) {
      cb(err) // new Left(err)
    } else {
      cb(null, user) // new Right(user)
    }
  })
}

asyncFunc('1', (err, user) => {
  if (err) console.error(err) // Left
  else console.log(user) // Right
})

Left and Right are baked into the syntax of callbacks. If err, do the Left thing, else do the Right thing. This worked well for callbacks, but when Promises came out, a lot of people moved on.

const promiseFunc = userID => new Promise((resolve, reject) => {
  getUserByID(userID, (err, user) => {
    if (err) {
      reject(err) // new Left(err)
    } else {
      resolve(user) // new Right(user)
    }
  })
})

promiseFunc('1')
  .then(user => console.log(user)) // Right
  .catch(err => console.error(err)) // Left

Promises are eerily similar to the Either monad. It's as if Promises were Left, Right, and Either rolled up into one. The thing about Promises though is that they were not created for the sole purpose of expressing a Left and a Right path. Instead, they were created to model asynchronous operations, with left and right paths necessitated by design.

With async/await, we have the latest in error handling

try {
  const user = await promiseFunc('1')
  console.log(user) // Right
} catch (err) {
  console.error(err) // Left
}

With the latest async/await syntax, the try catch block is the current prescribed way to handle errors. If you're happy with try catch blocks, you could stop reading here and be off on your merry way. However, before you go, I should mention there's a clean way to handle errors via a library function (authored by yours truly). Hailing from my functional programming library, rubico, it's tryCatch!

/*
 * @synopsis
 * <T any>tryCatch(
 *   tryer (x T)=>any,
 *   catcher (err Error, x T)=>any,
 * )(x T) -> Promise|any
 */

tryCatch(
  async userID => {
    const user = await promiseFunc(userID)
    console.log(user) // Right
  },
  err => console.error(err), // Left
)('1')

tryCatch(
  jsonString => {
    const parsed = JSON.parse(jsonString)
    console.log(parsed) // { a: 1, b: 2, c: 3 }
  },
  err => console.error(err),
)('{"a":1,"b":2,"c":3}')

rubico's tryCatch is cool because it catches all errors, synchronous or asynchronous. I personally like it because I like only needing one interface to handle all kinds of errors. One could argue that try catch with await would do the same thing, but at that point you're already in Promise land and cannot go back to synchronous land. rubico's tryCatch will behave completely synchronously for a synchronosly thrown Error. The sync vs async Promise correctness of rubico might seem insignificant at first, but it really is nice in practice for this to be a guarantee and not have to worry about it. If you would like to start functional programming on a similar level of bliss, check out rubico today.

Finally, I love monads. I think they're super cool, but they should only be used in places where they actually do something better than you could with vanilla JavaScript. Using monads for the sake of using monads is, well, meh. My belief is JavaScript has its own class of monads - monads that benefit the multi-paradigm language that is JavaScript. If you know of such a monad, I would love to hear about it in the comments.

Thanks for reading! This concludes my series Practical Functional Programming in JavaScript. You can find the rest of the series on rubico's awesome resources. If you have something you would like me to blog about, I would also love to hear it in the comments.

Cover photo credits:
https://resilientblog.co/inspirational/quotes-about-mountains/

Sources:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error
https://en.wikipedia.org/wiki/Monad_(functional_programming)
https://en.wikipedia.org/wiki/Kleisli_category

Practical Functional Programming in JavaScript - Control Flow

Richard Tong — Thu, 23 Jul 2020 19:21:54 +0000

Usually when authors use the terms "functional programming" and "control flow" together in the same sentence, it's to say functional programming should not have control flow.

"Chapter 1. (Avoiding) Flow Control" - Functional Programming in Python
"Destroy All Ifs" - A Perspective from Functional Programming
"More precisely, in true functional programming, there is no control flow." - Functional Programming in JavaScript, Part 1: The Unit

I'm using the wikipedia definition for control flow in this case

control flow (or flow of control) is the order in which individual statements, instructions or function calls of an imperative program are executed or evaluated

Control flow explicitly refers to statements, which are different from expressions. Where JavaScript is concerned, statements have semicolons and expressions do not. This is an important distinction, and means the difference between imperative and functional programming in JavaScript.

a + b;
// a, b and a + b are expressions
// a + b; is a statement

All of the articles above avoid if statements and instead prefer language equivalents of the conditional (ternary) operator. I'm here to agree with them in technicality and diverge a bit in practice. I diverge because the conditional operator can get messy in practice; I'm here to offer a cleaner, more scalable way. More on this later on.

The conditional (also referred to as "ternary") operator takes three operands: a condition expression, an expression to evaluate on truthy condition, and an expression to evaluate on falsy condition. It's like if and else, but instead of statements (yes semicolons), you put expressions (no semicolons).

condition ? a : b // if condition, evaluate expression a, else evaluate expression b

Purely functional languages like Haskell don't have the notion of a semicolon; they rely on syntax resembling the conditional operator

if condition then a else b

Python also has conditional-like syntax

a if condition else b

As you can see, the concept of a "ternary", or that which is "composed of three parts", is common across languages. It just makes a ton of sense to express a choice with three things: if some condition, do this, else do that. With JavaScript, you can do this imperatively with if, else statements or functionally with the conditional operator.

// imperative
const describeNumber = number => {
  let description = '';
  if (number < 0) {
    description = 'negative';
  } else if (number === 0) {
    description = 'zero';
  } else {
    description = 'positive';
  }
  return description;
};

// functional
const describeNumber = number =>
  number < 0 ? 'negative'
  : number === 0 ? 'zero'
  : 'positive';

You can go pretty far with the conditional operator alone, but there will be times when something more expressive could help you solve your problems better. This is especially true for code with a lot of branching or complex data handling. For these cases, I've devised a clean and declarative way for you to express conditional flow with my functional programming library, rubico.

Consider an entrypoint to a basic node command line interface application that accepts flags. The application is very simple; all it does is print its own version and its usage.

// argv [string] => ()
const cli = argv => {
  if (argv.includes('-h') || argv.includes('--help')) {
    console.log('usage: ./cli [-h] [--help] [-v] [--version]');
  } else if (argv.includes('-v') || argv.includes('--version')) {
    console.log('v0.0.1');
  } else {
    console.log('unrecognized command');
  };
};

cli(process.argv); // runs when the cli command is run

This is nice and familiar, but it's imperative, and you're here about functional programming, after all. Let's refactor some functionality and use the conditional operator.

// flag string => argv [string] => boolean
const hasFlag = flag => argv => argv.includes(flag);

const USAGE = 'usage: ./cli [-h] [--help] [-v] [--version]';

// argv [string] => ()
const cli = argv =>
  hasFlag('--help')(argv) || hasFlag('-h')(argv) ? console.log(USAGE)
  : hasFlag('--version')(argv) || hasFlag('-v')(argv) ? console.log('v0.0.1')
  : console.log('unrecognized command');

cli(process.argv); // runs when the cli command is run

Now it's looking real cool, but don't you think there's a lot of argvs everywhere? It gets better with rubico.

switchCase - like the conditional operator, but with functions. Each function is called with the same input
or - like the logical or (||) operator, but with functions. Each function is called with the same input

const { or, switchCase } = require('rubico');

// flag string => argv [string] => boolean
const hasFlag = flag => argv => argv.includes(flag);

const USAGE = 'usage: ./cli [-h] [--help] [-v] [--version]';

const log = message => () => console.log(message);

// argv [string] => ()
const cli = switchCase([
  or([
    hasFlag('--help'),
    hasFlag('-h'),
  ]), log(USAGE),
  or([
    hasFlag('--version'),
    hasFlag('-v'),
  ]), log('v0.0.1'),
  log('unrecognized command'),
]);

cli(process.argv); // runs when the cli command is run

With switchCase and higher order logical functions like or, it's like you're just typing it as you're thinking it. If the argv has the flag --help or -h, print the usage. Otherwise, if it has the flag --version or -v, print the version v0.0.1. Otherwise, print unrecognized command. I think it's an intuitive way to go about expressing logic in functional programs.

My hope is with switchCase and the logical combining functions and, or, and not, we could have a good basis to scale conditional expressions in functional JavaScript beyond the conditional (ternary) operator. If you have any thoughts about this or anything, I would love to get back to you in the comments. Thank you for reading! I'll see you next time on Practical Functional Programming in JavaScript - Error Handling

You can find the rest of the series in rubico's awesome resources

Sources:

Practical Functional Programming in JavaScript - Techniques for Composing Data

Richard Tong — Wed, 15 Jul 2020 17:13:13 +0000

Welcome back to my series on practical functional programming in JavaScript. Today we'll go over techniques for composing data, that is best practices that make life easy when working with structured data inside and in between functions. Composing data has to do with the shape and structure of data, and is about as fundamental as transformation when it comes to functional programming in JavaScript. If all transformations are A => B, composing data deals with how exactly A becomes B when both A and B are structured data. From Geeks

Structured data is the data which conforms to a data model, has a well defined structure, follows a consistent order and can be easily accessed and used by a person or a computer program.

Structured data could represent anything from a user profile to a list of books to transactions in a bank account. If you've ever worked with database records, you've worked with structured data.

There's a ton of ways to go about composing data since the territory is still relatively undeveloped. Good data composition means the difference between easy to read/work with code and hard to maintain/annoying code. Let's visualize this by running through a structured data transformation. Here is some structured user data

const users = [
  {
    _id: '1',
    name: 'George Curious',
    birthday: '1988-03-08',
    location: {
      lat: 34.0522,
      lon: -118.2437,
    },
  },
  {
    _id: '2',
    name: 'Jane Doe',
    birthday: '1985-05-25',
    location: {
      lat: 25.2048,
      lon: 55.2708,
    },
  },
  {
    _id: '3',
    name: 'John Smith',
    birthday: '1979-01-10',
    location: {
      lat: 37.7749,
      lon: -122.4194,
    },
  },
]

Say we needed to turn this user data into data to display, for instance, on an admin panel. These are the requirements

Only display the first name
Show the age instead of the birthday
Show the city name instead of the location coordinates

The final output should look something like this.

const displayUsers = [
  {
    _id: '1',
    firstName: 'George',
    age: 32,
    city: 'Los Angeles',
  },
  {
    _id: '2',
    firstName: 'Jane',
    age: 35,
    city: 'Trade Center Second',
  },
  {
    _id: '3',
    firstName: 'John',
    age: 41,
    city: 'San Francisco',
  },
]

At a high level, users is structured as an array of user objects. Since displayUsers is also an array of user objects, this is a good case for the map function. From MDN docs,

The map() method creates a new array populated with the results of calling a provided function on every element in the calling array.

Let's try to solve the problem in one fell swoop without composing any data beyond the top level mapping.

Promise.all(users.map(async user => ({
  _id: user._id,
  firstName: user.name.split(' ')[0],
  age: (Date.now() - new Date(user.birthday).getTime()) / 365 / 24 / 60 / 60 / 1000,
  city: await fetch(
    `https://geocode.xyz/${user.location.lat},${user.location.lon}?json=1`,
  ).then(res => res.json()).then(({ city }) => city),
}))).then(console.log) /* [
  { _id: '1', firstName: 'George', age: 32, city: 'Los Angeles' },
  { _id: '2', firstName: 'Jane', age: 35, city: 'Trade Center Second' },
  { _id: '3', firstName: 'John', age: 41, city: 'San Francisco' },
] */

This works, but it's a bit messy. It may benefit us and future readers of our code to split up some functionality where it makes sense. Here is a refactor of some of the above into smaller functions.

// user {
//   name: string,
// } => firstName string
const getFirstName = ({ name }) => name.split(' ')[0]

// ms number => years number
const msToYears = ms => Math.floor(ms / 365 / 24 / 60 / 60 / 1000)

// user {
//   birthday: string,
// } => age number
const getAge = ({ birthday }) => msToYears(
  Date.now() - new Date(birthday).getTime(),
)

// user {
//   location: { lat: number, lon: number },
// } => Promise { city string }
const getCityName = ({ location: { lat, lon } }) => fetch(
  `https://geocode.xyz/${lat},${lon}?json=1`,
).then(res => res.json()).then(({ city }) => city)

These functions use destructuring assignment to cleanly grab variables from object properties. Here we see the beginnings of composing data by virtue of breaking down our problem into smaller problems. When you break things down into smaller problems (smaller functions), you need to specify more inputs and ouputs. You thereby compose more data as a consequence of writing clearer code. It's clear from the documentation that getFirstName, getAge, and getCityName expect a user object as input. getAge is further broken down for a conversion from milliseconds to years, msToYears.

getFirstName - takes a user with a name and returns just the first word of the name for firstName
getAge - takes a user with a birthday e.g. 1992-02-22 and returns the corresponding age in years
getCityName - takes a user with a location object { lat, lon } and returns the closest city name as a Promise.

Quick aside, what is a Promise? From MDN docs

The Promise object represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.

I won't go too much more into Promises here. Basically, if the return value is not here yet, you get a Promise for it. In getCityName, we are making a request to an external API via fetch and getting a Promise because sending a request and waiting for its response is an asynchronous operation. The value for the city name would take some time to get back to us.

Putting it all together, here is one way to perform the full transformation. Thanks to our good data composition, we can now clearly see the new fields firstName, age, and city being computed from the user object.

Promise.all(users.map(async user => ({
  _id: user._id,
  firstName: getFirstName(user),
  age: getAge(user),
  city: await getCityName(user),
}))).then(console.log) /* [
  { _id: '1', firstName: 'George', age: 32, city: 'Los Angeles' },
  { _id: '2', firstName: 'Jane', age: 35, city: 'Trade Center Second' },
  { _id: '3', firstName: 'John', age: 41, city: 'San Francisco' },
] */

This code is pretty good, but it could be better. There is some boilerplate Promise code, and I'm not the biggest fan of the way we're expressing the async user => ({...}) transformation. As far as vanilla JavaScript goes, this code is great, however, improvements could be made with library functions. In particular, we can improve this example by using all and map from my asynchronous functional programming library, rubico. And no, I don't believe we could improve this example using another library.

map is a function pretty commonly implemented by asynchronous libraries; for example, you can find variations of map in the Bluebird and async libraries. map takes a function and applies it to each element of the input data, returning the results of the applications. If any executions are Promises, map returns a Promise of the final collection.
You won't find all anywhere else but rubico, though it was inspired in part by parallel execution functions like async.parallel and Promise.all. all is a bit like Promise.all, but instead of Promises, it takes an array or object of functions that could potentially return Promises and evaluates each function with the input. If any evaluations are Promises, all waits for those Promises and returns a Promise of the final value.

We can express the previous transformation with functions all and map like this

// users [{
//   _id: string,
//   name: string,
//   birthday: string,
//   location: { lat: number, lon: number },
// }] => displayUsers [{
//   _id: string,
//   firstName: string,
//   age: number,
//   city: string,
// }]
map(users, all({
  _id: user => user._id,
  firstName: getFirstName,
  age: getAge,
  city: getCityName, // all and map will handle the Promise resolution
})).then(console.log) /* [
  { _id: '1', firstName: 'George', age: 32, city: 'Los Angeles' },
  { _id: '2', firstName: 'Jane', age: 35, city: 'Trade Center Second' },
  { _id: '3', firstName: 'John', age: 41, city: 'San Francisco' },
] */

No more Promise boilerplate, and we've condensed the transformation. I'd say this is about as minimal as you can get. Here, we are simultaneously specifying the output array of objects [{ _id, firstname, age, city }] and the ways we compute those values from the user object: getFirstName, getAge, and getCityName. We've also come full circle; we are now declaratively composing an array of user objects into an array of display user objects. Larger compositions are easy when you break them down into small, sensible compositions.

Of course, we've only scratched the surface. Again, there are a lot of directions your code can take when it comes to composing data. The absolute best way to compose data will come from your own experience composing data in your own code - I can only speak to my own pitfalls. With that, I'll leave you today with a rule of thumb.

If you need to get an object or array with new fields from an existing object or an array, use all.

Thanks for reading! You can find the rest of the articles in this series on rubico's awesome resources.

rubico v1.2 release notes

Richard Tong — Mon, 13 Jul 2020 21:54:03 +0000

rubico v1.2 is out! Here's a summary of the changes.

v1.2.0

flatMap; map + flatten
transform(f, init), reduce(f, init); init can be a function
rubico/x/defaultsDeep - deeply assign defaults
rubico/x/isDeepEqual - left deeply equals right? eager version of eq.deep
rubico/x/find - get the first item in a collection that passes the test
rubico/x/forEach - execute a function for each item of a collection, returning input
rubico/x/is - directly checks the constructor
rubico/x/isEqual - left strictly equals right? eager version of eq
rubico/x/isObject - is object?
rubico/x/isString - is string?
rubico/x/pluck - create a new collection by getting a path from every item of an old collection
rubico/x/unionWith - create a flattened unique array with uniques given by a binary predicate

Also renamed rubico.js -> esm.js. This is for esm imports like

import rubico from 'https://unpkg.com/rubico/esm.js'

Practical Functional Programming in JavaScript - Intro to Transformation

Richard Tong — Fri, 10 Jul 2020 16:01:12 +0000

Welcome back ladies and gentlemen to another round of Practical Functional Programming in JavaScript. Today we will develop some intuition on transformation - a process that happens when one thing becomes another. At the most basic level, transformation is thing A becoming thing B; A => B. This sort of thing happens quite a lot in programming as well as real life; you'll develop a strong foundation for functional programming if you approach problem solving from the perspective of transformations.

Here is a classic transformation: TransformerRobot => SportsCar

Here's a wikipedia definition of transformation:

transformation [of data] is the process of converting data from one format or structure into another format or structure.

Looks like transformation is a process, but what exactly is the "data" that we are converting? Here's a definition from the wikipedia article for data.

Data (treated as singular, plural, or as a mass noun) is any sequence of one or more symbols given meaning by specific act(s) of interpretation.

Data can be both singular or plural? What about poor old datum? I guess it didn't roll off the tongue so well. In any case, with this definition, we can refer to any JavaScript type as data. To illustrate, here is a list of things that we can call data.

Just data things in JavaScript

a number - 1
an array of numbers - [1, 2, 3]
a string - 'hello'
an array of strings - ['hello', 'world']
an object - { a: 1, b: 2, c: 3 }
a JSON string - '{"a":1,"b":2,"c":3}'
null
undefined

I like functional programming because it inherently deals with transformations of data, aka transformations of anything, aka As becoming Bs (or hopefully, if you're a student, Bs becoming As). Pair that with JavaScript and you have transformations that come to life. We will now explore several transformations.

Here's a simple transformation of a value using a JavaScript arrow function:

const square = number => number ** 2

square(3) // 9

square is a function that takes a number and transforms it into its square. number => squaredNumber. A => B.

Let's move on to transformations on collections. Here is a transformation on an Array using square and the built in .map function on the Array prototype.

const square = number => number ** 2

const map = f => array => array.map(f)

map(square)([1, 2, 3]) // [1, 4, 9]

To get our new Array, we map or "apply" the function square to each element of our original array [1, 2, 3]. We haven't changed square, we've just used it on each item of an array via map. In this case, we've transformed the data that is the array [1, 2, 3] into another array [1, 4, 9]. Putting it in terms of A and B: map(a => b)(A) == B.

The following statements are equivalent

map(square)([1, 2, 3]) == [1, 4, 9]
map(number => number ** 2)([1, 2, 3]) == [1, 4, 9]
map(number => number ** 2)(A) == B
map(a => b)(A) == B

When you map, all the as in A have to become bs in B to fully convert A to B. This is intuition for category theory, which I won't go into too much here. Basically A and B are nodes of some arbitrary category, lets say Arrays, and map(a => b) is an "arrow" that describes how you get from A to B. Since each a maps one-to-one to a b, we say that map(a => b) is a linear transformation or bijective transformation from A to B.

Here's another kind of transformation on collections for filtering out elements from a collection. Just like .map, you can find .filter on the Array prototype.

const isOdd = number => number % 2 === 1

const filter = f => array => array.filter(f)

filter(isOdd)([1, 2, 3]) // [1, 3]

When we supply the array [1, 2, 3] to filter(isOdd), we get [1, 3]. It's as if to say we are "filtering" the array [1, 2, 3] by the function isOdd. Here is how you would write filter in terms of A and B: filter(a => boolean)(A) == B.

The following statements are equivalent

filter(isOdd)([1, 2, 3]) == [1, 3]
filter(number => number % 2 === 1)([1, 2, 3]) == [1, 3]
filter(number => number % 2 === 1)(A) == B
filter(a => boolean)(A) == B

Unlike map, filter does not convert as into bs. Instead, filter uses boolean values derived from as given by the function a => boolean to determine if the item should be in B or not. If the boolean is true, include a in B. Otherwise don't. The transformation filter(a => boolean) transforms A into a subset of itself, B. This "filtering" transformation falls under the general transformations.

Our last transformation is a generalized way to say both map(a => b)(A) == B and filter(a => boolean)(A) == B. Hailing once again from the Array prototype, welcome .reduce. If you've used reduce before, you may currently understand it under the following definition:

The reduce() method executes a reducer function (that you provide) on each element of the array, resulting in single output value.

I fully endorse this definition. However, it isn't quite what I need to talk about transformation. Here's my definition of reduce that fits better into our context.

The reduce() method executes a transformation F (A => B) defined by a reducer function and initial value

All this definition says is a general formula for transformations is reduce(reducerFunction, initialValue) == F == A => B. Here is a quick proof.

const reduce = (f, init) => array => array.reduce(f, init)

const sum = reduce(
  (a, b) => a + b, // reducerFunction
  0, // initialValue
) // F

sum( // F
  [1, 2, 3, 4, 5], // A
) // 15; B

// sum([1, 2, 3, 4, 5]) == 15
// F(A) == B
// F == (A => B)
// QED.

It follows that reduce(reducerFunction, initialValue) can express any transformation from A to B. That means both map(a => b)(A) == B and filter(a => boolean)(A) == B can be expressed by reduce(reducerFunction, initialValue)(A) == B.

reducerFunction can be expressed as (aggregate, curValue) => nextAggregate. If you've used or heard of redux, you've had exposure to reducer functions.

The reducer is a pure function that takes the previous state and an action, and returns the next state.

(previousState, action) => nextState

initialValue is optional, and acts as a starting value for aggregate. If initialValue is not provided, aggregate starts as the first element of A.

I will now rewrite our Array .map example from before with .reduce.

const square = number => number ** 2

// reduce(reducerFunction, initialValue)
const map = f => array => array.reduce(
  (prevArray, curValue) => [...prevArray, f(curValue)], // reducerFunction
  [], // initialValue
)

map(square)([1, 2, 3]) // [1, 4, 9]

// map(square)(A) == B
// F(A) == B

Each iteration for a given array, tack on f(curValue) to the end of the prevArray.

Here's our previous Array filter example with reduce.

const isOdd = number => number % 2 === 1

// reduce(reducerFunction, initialValue)
const filter = f => array => array.reduce(
  (prevArray, curValue) => (
    f(curValue) ? [...prevArray, curValue] : prevArray
  ), // reducerFunction
  [], // initialValue
)

filter(isOdd)([1, 2, 3]) // [1, 3]

// filter(isOdd)(A) == B
// F(A) == B

Each iteration for a given array, tack on curValue to the end of the prevArray only if f(curValue) is truthy.

So yeah, reduce is cool and can do a lot. I should warn you that even though it's possible to write a lot of transformations in terms of reduce, map and filter are there for a reason. If you can do it in map or filter, don't use reduce. That said, there are certain things even Array .reduce cannot do. These things include

reducing values of any iterable
reducing values of an async iterable
reducing values of an object

I think it is valuable to be able to transform these things, so I authored a functional programming library, rubico, with a highly optimized reduce that works on any collection. The same goes for map and filter. In addition, any functions you supply to these special transformation functions (or for that matter any function in rubico) have async and Promises handled automagically. That's because functional code that actually does stuff shouldn't care about async - it takes away from the mathiness.

I'll leave you today with some guidelines for map, filter, and reduce.

If you want to apply a function to all elements of a collection, use map
if you want to get a smaller collection from a larger collection based on some test, use filter
Most everything else, use reduce

I hope you enjoyed this longer-ish intro to transformation. If you have any questions or comments, please leave them below. I'll be here all week. Also you can find the rest of my articles on my profile or in the awesome resources section of rubico's github. See you next time on Practical Functional Programming in JavaScript - Techniques for Composing Data

Practical Functional Programming in JavaScript - Side Effects and Purity

Richard Tong — Thu, 02 Jul 2020 16:09:55 +0000

Edit: This article doesn't do such a great job at communicating what I originally intended, so it has a revision. I recommend you read the revised version, though I've left this original for historical purposes.

Hello 🌍. You've arrived at the nth installment of my series on functional programming: Practical Functional Programming in JavaScript. On this fine day I will talk about a two-pronged approach to problem solving that makes life easy: Side Effects and Purity.

Let's talk about purity. A function is said to be pure if it has the following properties:

Its return value is the same for the same arguments
Its evaluation has no side effects (source)

Here's side effect from stackoverflow:

A side effect refers simply to the modification of some kind of state - for instance:

Changing the value of a variable;

Writing some data to disk;

Enabling or disabling a button in the User Interface.

Here are some more instances of side effects

reading data from a file
making a request to a REST API
writing to a database
reading from a database
logging out to console

Basically, all interactions of your function with the world outside its scope are side effects. You have likely been using side effects this whole time. Even the first "hello world" you logged out to the console is a side effect.

In a world full of side effects, your goal as a functional programmer should be to isolate those side effects to the boundaries of your program. Purity comes into play when you've isolated the side effects. At its core, purity is concerned with data flow, as in how your data transforms from process to process. This is in contrast to side effects, which are only concerned with doing external stuff. The structure of your code changes for the clearer when you separate your programming concerns by side effects and purity.

Here is an impure function add10:

let numCalls = 0

const add10 = number => {
  console.log('add10 called with', number)
  numCalls += 1
  console.log('add10 called', numCalls, 'times')
  return number + 10
}

add10(10) /*
> add10 called with 10
> add10 called 1 times
> 20
*/

add10 has the side effects of logging out to the console, mutating the variable numCalls, and logging out again. The console logs are side effects because they're logging out to the console, which exists in the world outside add10. Incrementing numCalls is also a side effect because it refers to a variable in the same script but outside the scope of add10. add10 is not pure.

By taking out the console logs and the variable mutation, we can have a pure add10.

let numCalls = 0

const add10 = number => number + 10

console.log('add10 called with', 10) // > add10 called with 10

numCalls += 1

console.log('add10 called', numCalls, 'times') // > add10 called 1 times

add10(10) // > 20

Ah, sweet purity. Now add10 is pure, but our side effects are all a mess. We'll need the help of some higher order functional programming functions if we want to clean this up.

You can find these functions in functional programming libraries like rubico (authored by yours truly), Ramda, or RxJS. If you don't want to use a library, you can implement your own versions of these functions in vanilla JavaScript. For example, you could implement minimal versions of the functions we'll be using, pipe and tap, like this

const pipe = functions => x => {
  let y = x
  for (const f of functions) y = f(y)
  return y
}

const tap = f => x => { f(x); return x }

We'll use them to make it easy to think about side effects and purity.

pipe takes an array of functions and chains them all together, calling the next function with the previous function's output. Since pipe creates a flow of data in this way, we can use it to think about purity. You can find a runnable example in pipe's documentation.
tap takes a single function and makes it always return whatever input it was passed. When you use tap on a function, you're basically saying "don't care about the return from this function, just call the function with input and give me back my input". Super useful for side effects. You can find a runnable example in tap's documentation.

Here's a refactor of the first example for purity while accounting for side effects using pipe and tap. If the example is looking a bit foreign, see my last article on data last.

const logCalledWith = number => console.log('add10 called with', number)

let numCalls = 0

const incNumCalls = () => numCalls += 1

const logNumCalls = () => console.log('add10 called', numCalls, 'times')

const add10 = number => number + 10

pipe([
  tap(logCalledWith), // > add10 called with 10
  tap(incNumCalls),
  tap(logNumCalls), // > add10 called 1 times
  add10,
])(10) // > 20

We've isolated the console log and variable mutation side effects to the boundaries of our program by defining them in their own functions logCalledWith, incNumCalls, and logNumCalls. We've also kept our pure add10 function from before. The final program is a composition of side effecting functions and a pure function, with clear separation of concerns. With pipe, we can see the flow of data. With tap, we designate and isolate our side effects. That's organized.

Life is easy when you approach problems through side effects and purity. I'll leave you today with a rule of thumb: if you need to console log, use tap.

Next time, I'll dive deeper into data transformation with map, filter, and reduce. Thanks for reading! You can find the rest of the series on rubico's awesome resources. See you next time for Practical Functional Programming in JavaScript - Intro to Transformation

Practical Functional Programming in JavaScript - Data Last

Richard Tong — Wed, 24 Jun 2020 18:09:38 +0000

Welcome back to my series on practical functional programming in JavaScript. This time, I'll elaborate on a core functional programming concept that causes a lot of confusion for newcomers to functional programs: data last.

For the most comfortable read, you should have knowledge of Array.prototype.map and decent programming fundamentals.

Note: I use methods from my functional programming library rubico in a couple places to illustrate my points. I link documentation where applicable.

What is data last?

Data last is a programming convention wherein the data of a procedure is provided as the last parameter. This is in contrast to data first, where the data is the first parameter - you are probably more used to seeing this one.

This is data first. Quite literally, the Array (our data) is first.

[1, 2, 3, 4, 5].map(number => number * 2) // > [2, 4, 6, 8, 10]

This is data last. The Array (our data) is now last.

map(number => number * 2)([1, 2, 3, 4, 5]) // > [2, 4, 6, 8, 10]

map in this case is a partially applied function from rubico.

Documentation for map

Why does this matter?

Consider the program

const double = x => x * 2

const square = x => x * x

const doubleSquare = n => {
  const doubled = double(n)
  const squared = square(doubled)
  return squared
}

doubleSquare(3) // > 36

doubleSquare here is rather hand-holdy and imperative. However, since data is last for both double and square, we can rewrite doubleSquare using the functional approach in terms of just the two functions.

const double = x => x * 2

const square = x => x * x

const doubleSquare = pipe([
  double,
  square,
])

doubleSquare(3) // > 36

Documentation for pipe

Look ma, no variables! Data last allows us to write larger programs as compositions of smaller ones. This is a powerful concept for code reuse, and core to the functional programming paradigm. This idea is extensible at any scale; from small scripts to production workloads, anything you can represent with a function falls under this model.

I'll leave you today with a couple excerpts from the Unix philosophy:

Write programs that do one thing and do it well.
Write programs to work together.

We just discovered a powerful way for programs to work together via a simple convention: data last. Next time, we'll examine how we can consistently write programs that do one thing and do it well. Be on the lookout for Side Effects and Purity.

Edit: You can find the rest of the series on rubico's awesome resources

Practical Functional Programming in JavaScript - Why it's worth it

Richard Tong — Mon, 15 Jun 2020 00:16:04 +0000

Welcome to my series on Practical Functional Programming in JavaScript. In this installment, I talk about why it's worth it for you to go through all the trouble of learning functional programming in the first place. For the best reading experience, you should have programming fundamentals and familiarity with ES6+ JavaScript.

The biggest reason why you should learn functional programming is
you will become a much better programmer. Your programs will start to look as if they were written in plain English, and you will gain expressive power beyond your wildest dreams.

This is because functional programming is a natural way for humans to think about programs. Functional programming is declarative, meaning you declare what you want from the computer. In this way, you bend the computer to your will.

I'll show you what I mean with two functions, doubleArrayWithLoop and doubleArrayWithMap. Both functions take an array and return an array with every element multiplied by 2.

const doubleArrayWithLoop = arr => {
  const doubled = []
  for (let i = 0; i < arr.length; i++) {
    doubled.push(arr[i] * 2)
  }
  return doubled
}

const doubleArrayWithMap = arr => arr.map(number => number * 2)

doubleArrayWithLoop([1, 2, 3]) // > [2, 4, 6]
doubleArrayWithMap([1, 2, 3]) // > [2, 4, 6]

Right off the bat, doubleArrayWithLoop may appear more natural if you're more accustomed to loops. Here is a rough translation of what is going on.

In doubleArrayWithLoop, take an array arr, create a new array doubled, then start a for loop with i initialized to 0. Every iteration of the loop, push onto doubled the value of arr at index i multiplied by 2. After iteration is complete, return doubled.

It's just a tad bit wordy. Notice how doubleArrayWithMap reads a bit more like plain English.

In doubleArrayWithMap, take an array arr and return an array with each number of arr multiplied by 2.

It reads as if I copy and pasted from the two functions' description from above. Indeed, doubleArrayWithMap is the more functional of the two approaches because we are able to declare at a high level what we want. With doubleArrayWithLoop, we have to hold the computer's hand, telling it step by step how to give us what we want. This is the difference in expressive power between a program adhering to functional programming principles and a program that does not. This is also in part why there's so much hype over functions like map, which you'll run into over and over again in your functional programming journey.

You can find the rest of the series on rubico's awesome resources

🙅‍♂️ Stop trying to learn RxJS

Richard Tong — Tue, 09 Jun 2020 19:57:51 +0000

If you have any interest in RxJS, this article is for you. If you have no idea what RxJS is, I advise you not to worry about it and check out rubico: a new asynchronous functional programming library authored by yours truly.

At the highest level, the relationship between rubico and RxJS is characterized by convergent evolution, that is

the independent evolution of similar features in species of different periods or epochs in time

Emphasis on different periods in time. One period without async iterables, and one period in the future when they're a thing.

For the longest time, I had at best a hazy idea of RxJS. In fact, My first encounter with the reactive paradigm was through talks of RxSwift with a pal of mine from an old job. It wasn't until after I had heard numerous comparisons of RxJS to rubico that I really hunkered down and dove in.

This set me off to learn RxJS, and I'll be honest, I was disappointed. At no point in either of the release branches or the main site do they talk about why RxJS. It always just starts with what. It's like reading a research paper that starts with "hey guys, here's our research! it's important because we say so!". There needs to be a reason why the research is being done, otherwise no one will care. Just take a look at any TC39 proposal, it always starts with why. For RxJS, on the other hand, the current first time experience on the site is

Introduction - "RxJS is..." <- this is what
Example 1 - RxJS is powerful because you can use pure functions and pure functions are less error prone
Example 2 - RxJS has operators for flow control
Example 3 - RxJS has operators to transform values in RxJS observables
Observables - "Observables are..."

They never answered my first question: why is this here in the first place? On rubico it's

Motivation - Why is this here? Because When I was still writing in the imperative style, I got tired of looking at my own code. I created this library for myself, so I can write in a style I love.
Principles - What is the highest level of what I want from this library? Simple code; don't care about async; and simple, composable, and performant transformations (on all collections)
rubico follows these principles to grant you freedom
Introduction - take the tour, read the docs
Examples...

Why should always precede what. Otherwise, your product will run in circles. I experienced this first hand at my previous company.

From the creator of RxJS

RxJS isn't easy to learn. But the alternative lessons you'll learn if you try to roll your own streaming paradigm for your app with a lot of streaming data will be much, much more painful and costly.

I mean I can't predict the future, but I agree. I trust that the creator of RxJS speaks from experience. There will probably be a lot of pain rolling my own streaming paradigm, which is why I'm not going to roll my own streaming paradigm. In fact, I'm not going to invent another paradigm at all; I'm just going to borrow the existing functional paradigm and polish it for JavaScript.

...and at the end of the day, anything you create will just be another flavor of Observable without the safety guarantees.

Does the async iterable count as another flavor of the Observable? It seems the spec is leaving RxJS behind when async iterables are already here to stay, while Observables are a stage 1 proposal. Observables are not async iterables, but they compete for the same streaming data model. Async Iterables were created partly because of the pains of NodeJS streams, which are analogs to RxJS Observables. Part of these pains are backpressure problems, from RxJS creator:

Since observables are all push-based, there are memory and back pressure concerns unless you use a lossy strategy to adapt the incoming values into the asyncIterator. I have a proposal to add this as a feature to RxJS, but it's not without it's drawbacks.

^ that turned into this library.

You can see excitement for async iterable streams in this issue in the streams spec. Read it for the good vibes. Here's a nice summary from domenic

It's starting to feel a bit magic though....

Really, I'm just against spaghetti code. You'll get spaghetti if you model streams as a push datatype like Observable. You'll get worry free code if you model streams as async iterables. Finally, you'll get magical code if you feed an async iterable to rubico's transform. Check out this functional style async iterable webserver with rubico and deno

const s = serve({ port: 8001 });
console.log("http://localhost:8001/");
transform(map(req => {
  req.respond({ body: "Hello World\n" });
}), null)(s);

Here's my abridged list of features and roadblocks comparing RxJS and rubico. I encourage you to voice any additions or subtractions in the comments.

Features of RxJS	Features of rubico
special asynchronous stream datatype, the Observable - wraps built-in types for reactive operations down the line	no special data types: rubico works out of the box for built-in types; this includes async iterables
familiar design pattern: the Observer pattern - plugs into Observables	no design pattern lock-in: rubico composes your functions together. You choose the design pattern
interop with Promises	fully managed Promises: rubico stops you from having to manually resolve Promises, for example having to call `Promise.all` on an array of Promises
functional programming style via Operators + `Observable.prototype.pipe`	functional programming style by design

Roadblocks for RxJS	More Features of rubico
async iterables undermine the need for rxjs's core datatype: the Observable.	async iterables make rubico great; the async iterable is a core rubico (and JavaScript) datatype
multitude of concepts	simple foundational concept: just pipe functions together
large API surface	small, cohesive API surface
RxJS is hard to learn	rubico is easy to learn

I'm telling you to stop learning and using RxJS because rubico is that much better at doing what RxJS is trying to do. Don't get me wrong, rubico is easy to learn, but it takes time and hard work to master. I urge you to put your time to better use: take the tour.

rubico simplifies asynchronous code

Richard Tong — Sat, 30 May 2020 05:28:22 +0000

You are suddenly dropped into a world where all people write code in assembly.

There is no "High Level Language", only "Assembly Language". There is no C, just ASM. There are no variables, only registers. You are in charge of managing all memory in your programs: moving data from register to register, pushing and poping data on the hardware supported stack.

How would you write a webserver, or a database? How long would that take? How much longer would it take you to do whatever it is that you are currently doing?

We need not stay here any longer.

...interdimensional warp...

Welcome back to reality, where the world is rife with programming languages above assembly

How did this come to be? Why would anyone not want to spend their day to day in assembly?

According to an answer thread on stack overflow,

ASM has poor legibility and isn't really maintainable compared to higher-level languages.

[Assembly] takes more code to do the same thing as in a high-level languge, and there is a direct correlation between lines of code and bugs.

Another take from wikipedia

In contrast to low-level programming languages, [high-level programming languages] may use natural language elements, be easier to use, or may automate (or even hide entirely) significant areas of computing systems (e.g. memory management), making the process of developing a program simpler and more understandable than when using a lower-level language.

Perhaps the abundance of higher level languages comes down to readability versus performance

First code for correctness, then for clarity (the two are often connected, of course!). Finally, and only if you have real empirical evidence that you actually need to, you can look at optimizing.

IMO the obvious readable version first, until performance is measured and a faster version is required.

I would go for readability first.

Great, looks like people are for clarity, so where does that leave us? And what does any of this have to do with rubico?

Consider these two samples of JavaScript code. Both execute an asynchronous function for every element of an array

Promise.all(array.map(doAsyncThing)) // vanilla JavaScript

map(array, doAsyncThing) // rubico

It looks like you can write a little less to do the same thing with rubico. Is the rubico version more readable? I'd say it's up for debate.

What if we wanted to do multiple asynchronous things in parallel for every item of the array?

Promise.all([
  Promise.all(array.map(doAsyncThingA)),
  Promise.all(array.map(doAsyncThingB)),
  Promise.all(array.map(doAsyncThingC)),
]) // vanilla JavaScript

map(array, all([
  doAsyncThingA,
  doAsyncThingB,
  doAsyncThingC,
])) // rubico

It looks like vanilla JavaScript has four more Promise.all statements, and two more map keywords. rubico, on the other hand, has one map and one fork. Simpler? It's starting to look like it. More readable? Hold your horses.

What if we now want to do another async thing per item of each of the responses?

Promise.all([
  Promise.all(array.map(doAsyncThingA).then(
    arrayA => Promise.all(arrayA.map(doAsyncThingAA))
  )),
  Promise.all(array.map(doAsyncThingB).then(
    arrayB => Promise.all(arrayB.map(doAsyncThingBB))
  )),
  Promise.all(array.map(doAsyncThingC).then(
    arrayC => Promise.all(arrayC.map(doAsyncThingCC))
  )),
]) // vanilla JavaScript

map(array, all([
  pipe([doAsyncThingA, map(doAsyncThingAA)]),
  pipe([doAsyncThingB, map(doAsyncThingBB)]),
  pipe([doAsyncThingC, map(doAsyncThingCC)]),
])) // rubico

I think it's safe to say that rubico is more expressive here. I'll let you be the judge of whether something is more readable; though I will say this: rubico cuts out a lot of cruft.

Back to assembly. You could compare what rubico does for JavaScript to what C does for assembly.

In contrast to assembly, C uses natural language elements, is easier to use, and automates (but doesn't hide entirely) memory management. C makes the process of developing a program simpler and more understandable than when using assembly.

In contrast to vanilla JavaScript, rubico automates (hides entirely) the cruft surrounding Promises. rubico makes the process of developing a program simpler and more understandable than when using vanilla JavaScript.

I should also mention that when you use rubico, you get the benefits of the functional programming paradigm (but not the confusion) for free.

If this motivated you to see what rubico's all about,
please 🌟read on🌟