DEV Community: Fahad Hossain

The Trials and Tribulations. A Fool's Guide To Writing Functional JS (Part 4)

Fahad Hossain — Sun, 16 Aug 2020 17:38:30 +0000

It's been a while since my last article so, hopefully you didn't forget what we last discussed. Throughout the last 3 articles I alluded to some nifty tricks and nice-ties like compose. So in this article we will try to cover some of these topics.

Let's see some problems that we come across when starting out our FP journey in JS.

Problem #1

If you have been writing functional code, or even just trying to avoid mutations and side-effects, you probably ended up writing something like this

const data = {
  /*...*/
}; // some data
const result = doSomethingCompletelyDiff(doSomethingElse(doSomething(data)));

At some point, making this kinda nested function calls becomes inevitable; specially if you don't want to make really specific, single-use functions. But this kind of function calls are not only ugly to look at, sometimes they are difficult to follow as well. Specially if you add some higher-order functions in between, then you've got a nasty mess of parentheses.

What if we had something that could combine multiple functions to a single function?

Solution:

We do have precisely that exact tool. (Un)surprisingly, it's another one of those things that we borrow from math.

Let's see it in math first.

Lets define a function f(x)

And another function g(x)

Lets take a letter y and let its value be...

We can see our old friend nested function call here again... So how did math come up with a solution?

They made an operator, of course. This operator allows you to define a function by composing multiple functions and as such, it's called the composition operator. Visually, it looks like a tiny circle.

Here's composition operator put to use,

Here, h is defined as the composition of g and f. Functionally, calling h(x) is the same as calling f(g(x)) So now, we can do this

"Great" I hear you say, "How does that help me in code, I can't just put a big ol' dot between two functions in JS can I?"

You can!

No, not put a big ol' dot... you can compose functions in JS just not using an operator.

It goes something like this

const newSuperFunction = compose(lastFn, secondFn, firstFn);

Doesn't look too horrible, if you ask me 🤷

"But where did this compose function come from, and how do I get one?" I hear you say

I'm glad you asked, remember our old friend the fold (reduce)? We can very easily define compose using a right fold (we discussed a left fold before, this is the same thing but from the other direction).

const compose = (...funcs) =>
  funcs.reduceRight(
    (fx, gx) => (...args) => gx(fx(...args))
  );

Here, our compose function takes a variadic number of arguments, all of which are functions.

Because of the rest operator we get the functions as an array, so we can call the built-in reduceRight function from the array prototype.

Then, we pass in a argument to the reduceRight call.

We pass a function that receives two functions as arguments, and returns an inline variadic function that calls the two functions successively with its arguments.

The variadic (any number of arguments) bit was added so that we can compose non-unary (more than one argument) functions too.

Happy composing, Enjoy!

Problem #2

Once you understood map, filter and reduce you just can't go back. You write code that looks like this

const dataSet = [
  /*...*/
]; // Some dataset
const finalData = dataSet
  .map(someTransformation)
  .map(someFurtherTransformation)
  .filter(somePredicate)
  .filter(anotherPredicate)
  .map(evenMoreTransformation)
  .reduce(combinatorFunction);

While this code is very contrived but you get the idea. If you don't want to make a bunch of one-off transformations and predicates you end up doing this.

Even if it might not seem like a problem at first, you will start to see a crash coming from miles away as soon as your dataset becomes large enough.

The problem with this kind of code is that every map and filter and reduce call is an iteration. In imperative code you might be used to doing a lot of transformation and filtering out in a single loop, which looks almost impossible to do here.

Solution:

Just a word of warning, there are better solutions out there. But, for now we can discuss some simple ones that will help you write better code regardless of better solutions. If these do not help your use case enough, do a little digging into transducers.

Combine successive transformations/maps

  .map(someTransformation)
  .map(someFurtherTransformation)

Can be rewritten using our friend compose like this

  .map(compose(someFurterTransformation, someTransformation))

While the benefit may not be obvious, what you are essentially doing is that you are running 2 transformations in a single iteration rather than running 2 iterations with 1 transformation each. Which means, 1 less iteration but the same result

Combine successive filters

You might get the idea that we can combine filters the same way we combined maps.
However, the moment you go to do such a thing, you realise that you forgot that composing predicates just won't work.

But we can get around that by implement a logical and function to combine predicates, since that's essentially what two successive filters do anyway.

Let's try to implement a binary and function

  const and = (pred1, pred2) => (...args) => pred1(...args) && pred2(...args);

So now we can rewrite this

  .filter(somePredicate)
  .filter(anotherPredicate)

to this

  .filter(and(somePredicate, anotherPredicate))

You can combine more than two predicates by nesting calls to the and function. But I recommend checking out Ramda's allPass and both functions.

Why re-invent the wheel when the wheel is so nice?

Problem #3

I write too many helper functions like compose, pipe, etc.

This is a comment I hear from friend very often. And... I'll admit, I had this problem too. While writing helper functions isn't bad, it can be bad when you spend more time writing them than writing your business logic.

The reason why so many JS devs have this problem is that our language gives the very basic tools to get us hooked on FP and then leaves us high and dry and wanting more. So we end up implementing a lot of basic fundamental FP constructs ourselves.

Solution (not really, but it is what it is)

A lot of this can be avoided by adding a Functional utility library to your toolchain. I highly recommend Ramda, because it gives a lot of functionality at a very reasonable file size. All of its functions are at least on par with some language built-in implementations, if not better, in terms of performance. And the cherry on top, its tree-shakeable; so almost any build system like webpack or rollup can remove the functions you don't use from the final JS bundle.

That's enough problems for a day

Enjoy writing more FP code. I'll try to write about a few more problems and solutions.

Till then, Peace ✌️

Some Higher-Order Functions. A Fool's Guide To Writing Functional JS (Part 3)

Fahad Hossain — Fri, 12 Jun 2020 16:41:10 +0000

In the last article we discussed the basics of Functions. We saw some definitions and examples of Higher-Order Functions. But that might have left you high and dry.

You could be wondering,

How is any of this terminology useful to me?

Sure, now I know what functions are. How do I use them?

All these are very valid responses to that article, I didn't cover any day-to-day uses for Higher-Order Functions (the article was already getting too long).

So, in this article, we will try to use some common higher-order functions. Namely, map, filter, and fold(reduce).

A little refresher

A function is a mapping between some input and some output

A Higher-Order function is a function that maps between function(s) and data (as either input and/or output)

Let's get to it!

map

We'll get right to the definition.

According to wikipedia (and most literature),

map is the name of a higher-order function that applies a given function to each element of a functor

You might be cursing and saying

"What the F@#$ is a functor?"

Let's ignore that for now, and try to define map in a way that sounds (a bit more) human,

map is a function that takes a container data structure and applies a function to each value and creates a new container with the results of said application

Or,

map is a thing that takes a collection of things and gives you a new collection of things by applying a function over each thing

Notice how I'm trying to avoid naming any data structures?

That's partially to not piss of the FP neckbeards and the Lambda gods, but also to make it clear that map can be implemented in any data structure*. Like most FP concepts, it's very abstract and can be applied to a whole grocery list of things.

JavaScript only implements map (natively) in only one Data Structure, Array. It's implemented as a function on the Array prototype. But, it doesn't have to be tied down to Arrays (😉)

NOTE: If you are already familiar with Array.prototype.map, try not to think of it as a 1:1 implementation of the concept of map

Let's look at an example of using JavaScript's map.

let fruits = ["apple", "banana", "carrot"] // The collection

let firstLetter = str => str[0] // Our transformation

let firstLetters = fruits.map(firstLetter) // The new collection.
// => ['a', 'b', 'c']

So, what's happening here?

Let's start from the top, we defined an array named fruits and stored a few strings in it.

Next, we defined a function named firstLetter that takes a string input and return's its first character.

Then, we make a call to Array.prototype.map by invoking fruits.map with the argument firstLetter. What this is doing is, telling the map function to iterate over every element contained by fruits and apply firstLetter to each element, store the results in a new array, and then return the new resulting array. This return value is what we assign to firstLetters.


Illustration adapted from John Ferris' article

Note: Libraries like Ramda(seriously awesome, check it out) allow you to map over additional data structures such as objects. Let's try to implement a map (using mutable code) that works for both containers (object & array).

let map = function (func, ftor) {
  let result
  try {
    result = ftor.constructor()
  } catch (e) {
    result = {} // Some exotic container given, degrade to Object
  }
  for (let k in ftor)
    result[k] = func(ftor[k])
  return result
}

With this map there's a bunch of different things happening, but keep in mind that for an ordinary array, its functionally same.

Lets try to break it down,

Arguments: this function takes two arguments, func and ftor. As the name might imply, func is our function (the transformation). ftor might seem like a weird name for the second argument, this argument is your data structure (array, object, etc.).

So why is it called ftor and not something like data or array? Remember that word we used in the first definition (from Wikipedia)? Yeah Functor, ftor is my way of writing functor. A Functor is basically any data structure that you can map over*. So, in our case Object and Array (and potentially other data structures that store key->value) are both Functors from the perspective of our map function even though natively, only Arrays might be considered Functors.

Congrats! Now you know another FP buzzword/jargon.

Line 8-9: here, we are iterating through the keys of the container (indices in case of arrays) and applying the function func to each value and associating it with the same key in the resulting container.

Result: this function returns a container of the same type as the functor (by calling its constructor), in cases where it fails, I've decided to degrade down to a plain object.

Usage

This comes in handy when you need to make a collection of things from an existing collection by transforming each value.

filter

Once again, here goes the wikipedia definition

filter is a higher-order function that processes a data structure (usually a list) in some order to produce a new data structure containing exactly those elements of the original data structure for which a given predicate returns the boolean value true

This time, I think the wiki definition is very expressive. Put differently,

filter is a function that goes through a Filterable collection and makes a new collection that contains only the values for which the predicate returns true

That might sound like a mouthful, but the concept is simple (you will see for yourself once we go through an example).

Once again, JS has a native implementation of filter, but only in Arrays. Same as map, its implemented in the Array prototype. But it could be used with any **Filterable* data structure.*

Similar to Functors, a Filterable is a data structure that you can filter. Most Functors tend to be Filterable as well, but there is no guarantee that a Functor is Filterable. If we assume that Array.prototype.filter* is the only possible implementation of filter, then only Arrays can be considered Filterable. But, because we can write a function that can filter objects, we can consider plain JS objects as Filterable too.

Now you know another Category of data structures.

NOTE: It should go without saying, Array.prototype.filter may/may not be 1:1 with the spec of filter

Let's look at an example of JavaScript's filter.

// The collection
let fruits = ["apple", "orange", "banana"]

// The predicate (a function that returns either true or false)
let isCitrus = fruit => /lemon|lime|orange|grapefruit/i.test(fruit)

// The new collection
let citrusFruits = fruits.filter(isCitrus)

Let's start from the top, we defined an array named fruits and stored a few strings in it (same as our map example).

Next, we defined a function named isCitrus that takes a string input and checks it against a regular expression and returns either true or false.

Then, we make a call to Array.prototype.filter by invoking fruits.filter with the argument isCitrus. What this does is, tell the filter function to iterate over every element contained by fruits and call isCitrus with each element as argument, if isCitrus returns true that elements is kept, otherwise the element is skipped over and the next element is checked. This process is repeated for all the elements of the array. An array is constructed containing only the elements for which isCitrus returned true.


Illustration adapted from John Ferris' article

Let's try to implement a filter (using mutable code) that works for different containers (object & array).

let filter = function (predicate, filterable) {
  let result
  try {
    result = filterable.constructor()
  } catch (e) {
    console.warn('Error on trying to call ', filterable.constructor, e)
    result = {}
  }
  let arrKey = 0;
  let isArray = Array.isArray(filterable)
  for (let key in filterable) {
    if (predicate(filterable[key])) {
      let newKey = isArray ? arrKey++ : key;
      result[newKey] = filterable[key]
    }
  }
  return result
}

With this filter there's a bunch of different things happening, but keep in mind that for an ordinary array, its functionally the same as calling Array.protorype.filter.

Lets try to break it down,

Arguments: this function takes two arguments, predicate and filterable. As the name might imply, predicate is our predicate (a function that takes a value and returns either true or false). The argument filterable is your data structure (array, object, etc.).

Line 11-16: here, we are iterating through the keys of the container (indices in case of arrays) and checking if the predicate returns true for a particular value. If a value does return true, we are keeping it in the result container.

Result: this function returns a container of the same type as the filterable (by calling its constructor), in cases where it fails, I've decided to degrade down to a plain object.

Usage

This comes in handy when you need to make a collection of things from an existing collection by keeping values that meet a certain criteria.

fold (reduce)

You know the drill, wiki first

fold (also termed reduce...) are ... functions that analyze a recursive data structure and through use of a given combining operation, recombine the results of recursively processing its constituent parts, building up a return value.

Lots of stuff to unpack there, but lets try to get to the gist of it

fold is a function that goes trough a Foldable collection and accumulates a value using an accumulating function and then finally returns the accumulated value

To a shock to nobody, JavaScript has a native implementation of fold as well, its named Array.prototype.reduce. Once again we have to make the note that JS's reduce/fold can only fold arrays, but it doesn't have to be tied down to just JS arrays. A fold can be implemented for any data structure that can be classified as Foldable.

A data type is Foldable if we can implement some form of fold for it. But due to the nature of the fold operation, Foldables are usually list(array)-like or have a valid list-representation. While not strictly required, most Foldables tend to be Functor and Filterable as well. This is because both map and filter can be implemented using fold.

Another note, there are many variations of fold out there. The essential functionality is the same but some implementation details change the nature and name of the fold. In this article we will look at a left-fold as the native reduce method is a left-fold. This fold is also called foldl or fold_left in some languages and libraries.

Once again, disclaimer: JS reduce may not follow the spec of fold 100%.

Let's try using Array.prototype.reduce to do something.

// The collection
let fruits = ["apple", "banana", "orange"]

// The accumulating function
let makeSalad = (salad, fruit) => `${fruit}-${salad}`

// Inital Salad
let saladStarter = "salad"

// The Result
let salad = fruits.reduce(makeSalad, saladStarter) //=> orange-banana-apple-salad

Let's start from the top again, we defined an array named fruits and stored a few strings in it.

Next, we defined a function named makeSalad that takes two strings and returns a string by concatenating them.

We then define another variables, this time its a string named saladStarter.

Then, we make a call to Array.prototype.reduce by invoking fruits.reduce with the arguments makeSalad and saladStarter. What this does is, it tells the fold function to iterate over every element contained in fruits and call makeSalad with an accumulated value and an element from fruits. For the first iteration, there is no accumulated value, so makeSalad is called with saladStarter as the accumulated value. For every subsequent iteration, makeSalad is called with the return value of the previous iteration as the accumulated value and the next item in the array. This process is continued until makeSalad has been called with the accumulated value from its previous iteration and the last item in fruits. Finally the return value from the final call is passed on as the return value for the reduce call and stored in the variable named salad.


Illustration adapted from John Ferris' article

Let's try to implement a fold of our own. Using mutable and imperative code, of course.

let fold_left = function (folding_fn, inital_value, foldable) {
  let accumulated = inital_value
  for (let key in foldable) {
    accumulated = folding_fn(accumulated, foldable[key])
  }
  return accumulated
}

You might be thinking...

What? Where is all the code?

Folds are notoriously very simple to implement, but they are so useful that you'll find yourself wondering why more people don't use them.

I think its pretty obvious how this function works, so I won't bore you with the explanation. Let's instead come back to our claim that we can usually map and filter using a fold.

map

// le folded map
let map = (fn, ftr) => fold_left((acc, val) => acc.concat(fn(val)), ftr.constructor(), ftr)

Yeah, this code is not very readable, but its not meant to be. This is a one-liner that shows a very simple implementation of map using fold. It works because fold carries the return value from the accumulating function on to the next iteration, allowing us to successively construct a larger list of values resulting from applying fn to val. Try and tinker with it a little bit, and I have faith that you will figure it out.

On to the next one...

filter

// le folded filter
let filter = (pred, flt) => fold_left((acc, val) => pred(val) ? acc.concat(val) : acc, flt.constructor, flt)

Once again, this is a one-liner. This follows the same principle as map, except we are only concatenating to the list if the predicate is satisfied by the value (i.e., pred(val) returns true).

Usage

Folds should come in handy when you need to,

Iterate over a list and carry over a value to the next iteration
Fold a list onto itself to arrive at a single value
Transform a list to a single value (even if the resulting value is of a completely different type, like transforming the items of a list to be items of a Map or a Set)

Appendix / Additional Links

I talk briefly about a few Categories of data types. If you wanna look at more of these categories, take a look at the wonderful fantasy-land specifications that defines Algebraic Data Types in terminology we JS devs can understand.

Also check out the amazing ramda library for more useful functional utilities like performant and curried implementations of map, filter, reduce or even helper functions that help you easily combine these operations into a transducer (more on this in a later article).

If you are even slightly mathematically minded, lookup Category theory as well as Algebraic Data Types. These are wonderful topics to study regardless, but they also help us understand the world of FP even better.

That's all for today, folks.

Peace ✌️

Functions. A Fool's Guide To Writing Functional JS (Part 2)

Fahad Hossain — Sat, 25 Apr 2020 17:34:39 +0000

In the last article I introduced some core concepts of Functional Programming. In that article we quickly glossed over Pure Functions. In this article I try to discuss functions in more details.

If there is one thing that you can call absolutely necessary to do functional programming is a good understanding of Functions. (I guess you could infer that from the name, *Function*al Programming)

What is a function?

If you are a programmer of any kind, you are probably already familiar with functions. But, I will still ask you, what is a function?

I hear some JS folk going, I know what a function is:

function doSomething(x) {
  return x + 42;
}

Its this (👆) thing. Or this

const addTwo = function (x) {
  return x + 2;
}

Or the real clever guy thinking, its this


const addOne = x => x + 1

Yes, all of those are functions.
But those are examples of functions. What I want you to think about is,

What is a function? What does it do?

As you may/may not be aware, the world of computer science is very intertwined with the world of mathematics. Functions are one of many things that we borrow from the world of mathematics.

However, math is very abstract (for good reason). And so, if you look for a definition of functions in mathematics, you will find multiple. One that I like is,

A function is a relation between 2 sets

Or in less abstract, computer science-y terms

A function is a mapping between an input and an output

So, we can say that a function is a thing that takes some input and gives back some output.

Now there are several rules that a thing must follow before it can be considered a function, the most important ones are:

Multiple inputs can map to a single output

  // for a function fx,
  fx(1) // => true
  fx(-1) // => true

Same input can not map to multiple outputs.

This is because that would lead to non deterministic behaviour and this is undesirable in both computer science and math.

  fx(1) // it should not be true once and false the next second.

Now you may be thinking,

What about functions that don't return anything.

I don't know (nor care for the purposes of this discussion) about the behaviour of this in other languages, but in JS your functions always return something whether you want to or not.

If you do return something, that's well and good.
However, if you don't, JS returns undefined for you.

So your function that returns nothing, is actually a mapping from some input to undefined. But more importantly, you might be getting the results of such a function in some other place, maybe the function is pushing the result on to a variable outside its scope.
In that case, Its an impure function and its causing side effect. And you should probably avoid doing that (when possible).

But you might be thinking,

What about functions that don't take an input.

This can go one of several ways,

Your function always returns something valuable if you call it with no input.

Your function is a mapping from a null set (nothing) to a value, Its
a function.
Your function takes no input and returns nothing (or undefined) as we discussed.
1. Its useless (i.e. not doing anything), but Its a function.
2. Its useful (i.e. gives some output), but its output is not available as a return value, Its (probably) not a (pure) function and you should try and avoid these as its making a side effect!

So, we now know what functions are, that's it right? that's all there is to know about functions?

No, my dear reader. You can dig yourself into a tunnel, learning about functions. But, for our purposes of learning FP in JS. We can talk about some special types of functions that follow the rules above and do some interesting things.

Recursive Functions

Do you know what factorials are?
Its this thing you express in math with an exclamation mark after a number like 5!.

What's it do? Its an interesting bit of math, its useful for a lot of things that we are not going to discuss right now. The important bit is that we can not just use a number followed by and exclamation mark after it to get a factorial in code. We need to make that functionality ourselves.

Luckily, factorials are very intuitive. There's just two rules about factorials, and you can get the factorial of any number with those.

Factorial of 0 is 1.
Or,
0! = 1
Factorial of a number X is X multiplied by the factorial of (X-1).

Or,

n! = n ✕ (n-1)!
Example:
5! = 5 * 4!

So if we wanted to find the factorial of 3, it would go something like this,

3! = 3 * 2!
2! = 2 * 1!
1! = 1 * 0!
0! = 1

Simplifying,
3! = 3 * 2 * 1 * 1

If we wanted to implement this behaviour in a function and call it fac. How would you go about doing that?

You're probably thinking of loops and if-else statements. But there is a very simple way where we can take the rules of factorial word for word and translate that into code and it would work.

This is how it goes

function fac (n) {
  if (n === 0) return 1 // this is our rule number 1 being satisfied.
  return n * fac(n-1) // rule number 2 being satisfied
}

Thats it! This is a very simple and functioning implementation of factorial.

So, how does it work?

This is an example of a recursion; a function that calls itself to do something or get a result.

In every (intensional) recursion in the world, there are always at least 2 logical cases.

A base case where the function does not call itself (so the recursion is not infinitely spiralling out).
A recursive case where the function calls itself.

In the example above,
Line#2 is our base case. As you might have noticed, this is usually something that's either easily computable or known.
Line#3 is our recursive case, This is usually where we put the repetitive behaviour.

A word of warning,

While JavaScript is usually a good enough language for exploring functional concepts, this is one of the places where functional and JS doesn't necessarily agree.

A recursion is usually fine for simple algorithms that don't need too many recursive calls in JS. But, if your algorithms does a recursive call way too many times, its either not gonna perform well or going to crash because of a stack overflow.

In future, We might discuss techniques such as memoization to get over this kind of limitations or to make our code more performant than a naive recursion.

Higher-Order Functions

Lets get straight to the point, As previously discussed... A function is a mapping from input to an output.

A Higher-Order Function is a function that maps,

From function(s) (input) to output
From input to function
From function (input) to function (output)

Take a moment to absorb all of that. If a function does any of those 3 things, its a higher order function.

Lets see a few examples,

function propSatisfies(prop, pred, obj) {
  let val = obj[prop]
  return pred(val)
}

let data = {
  age: 21
}

function isAdult (age) {
  return age >= 18
}

propSatisfies('age', isAdult, data) //=> true

In the example above,

Our function propSatisfies takes in 3 parameters(inputs),
prop: a string (name of a property)
pred: a function that takes an input and returns true or false
obj: an object whose prop property will be checked against pred.
Our function returns a value, either true or false

On the last line, we call the propSatisfies function using 3 values,
prop => 'age'
pred => isAdult
obj => data

isAdult is a simple function that takes an age and returns true or false (i.e. a predicate). This is not a Higher-order Function
'age' is a string literal, so not a Higher-order Function
obj is an object, not a Higher-order Function.

So, which one is the Higher-order function? propSatisfies
Why? Because it maps a function (isAdult) to a value true or false.

Lets look at another Higher-order function.

function add(a) {
  return function (b) {
    return a + b;
  }
}

let addOne = add(1) //=> this returns a function
let addTen = add(10) //=> this too returns a function

addTen(1) //=> returns 11

In this example,
add is a function that takes in 1 parameter, a (A number).
Our function returns another function.

add, here, is a Higher-order Function, because it returns a function.

Our add function also employs another interesting FP concept called a closure, we will discuss how our function and closures work another day. For the purposes of this discussion just understand that add is a Higher-order function because it returns another function.

Let's look at a final function that does both of these things, take in function(s) and returns a function.

function combine(outer, inner) {
  return function (arg) {
    return outer(inner(arg))
  }
}

function double (num) {
  return 2 * num
}

function square (num) {
  return num * num
}

let dSquare = combine(square, double) //=> a function that doubles and then squares a number

In this example,
combine takes in two arguments outer and inner, both of which have to be functions. So, we can already see that it is a Higher-order Function
combine also returns a function that *combine*s the functionality of both inner and outer. Once again, its a higher-order function (because its returning a function)

When we call combine with square and double as arguments, it returns a function that takes an argument arg and returns a value by calling inner with arg and then calling outer with the return value of the inner call. In essence, combining the two functions. So, dSquare is now a function that, when given a number, doubles it first and then squares it and then returns the result of those operations.

In later articles, We will discuss a function that's basically combine but much more flexible and powerful. (For the really curious people, look up compose).

That's all for today, folks.

Peace ✌️

The Introduction. A Fool's Guide To Writing Functional JS (Part 1)

Fahad Hossain — Fri, 10 Apr 2020 18:57:22 +0000

You're a developer going about your day writing loops and pushing and deleting stuff from arrays and what not. And then some day you think 🤔

maybe I should test my code...

"Shouldn't be too hard", you say.

And then you get started, you learn the basics of unit testing and even write some tests. But as soon as your code gets a bit more complex, it starts to seem like almost impossible to test. But, you are determined, you're not gonna give up that easy; you start creating and destroying objects after every test. Maybe your chosen test framework even offers hooks for those.

But Imagine a world where you could test almost every piece of functionality in your code, without jumping through those hoops.

Well, that's not what I'm gonna teach you today 😅.

What we will try to discuss, however, are some of the basics of a paradigm called Functional Programming (or FP for short). What you can eventually get by following the principles of FP is what we previously discussed and more. Namely, easily testable code, minimal setup in testing, cool developer creds, happiness* 😅.

P.S. I can't promise that last one, what I can promise is good DX (Developer Experience) which may/may not correlate to happiness.

Right, Lets start!

What is FP?

I'm not gonna get into some complex mathematical/theoretical explanation of what FP is. I'll try to explain FP in very simple terms...

FP is a paradigm(a way of thinking about problems) where we solve problems in terms of functions^😉 and state that does not change(immutable state).

Foreword

A word of warning, FP (and almost all literature about FP) is filled with jargon such as "immutable", "functor", "monad", etc. Don't get discouraged, once you get familiar with them, you'll start to see why people use them (hint: to express ideas in short).

Unlike most traditional FP tutorials, I won't be showing any code in any purely functional language like Haskell or OCaml. While those are great language, I'm not great at them and I think JavaScript is good enough as a language to explore at least the basics of FP 😃

Core Principles (of FP)

Almost every religion comes with some core tenants that you must follow. While FP is not a religion, it does come with some rules that must be obeyed at all times (otherwise the FP gods will be very unpleased and you will suffer as a developer). But, this being me and not some FP guru, I might miss some and am most definitely paraphrasing all of them.

NEVER* mutate state
Don't cause side effects
If you do need have side effects, isolate and limit them to a small number of functions
Every piece of code that does something should be a function
Oh, and did I mention? NEVER MUTATE STATE

Don't worry about the jargon for now, we will discuss those terms shortly.

State (and mutation? 🤷‍♀️)

Lets begin by examining some objects in real life. Do you remember those digital watches (CASIO et al) from back in the day that lit up when you pressed a button on the side?


Image: Casio W-86 / W86 / W-86-1VQES "Illuminator" digital watch. Multicherry / CC BY-SA

Lets examine that mechanism. The "backlight" on those watches is a very simple green-ish LED soldered besides the digital display, powered by the on-board battery and sometimes a tiny little solar panel. If we think of that backlight and button mechanism as a simple program. We can observe a few things,

The backlight is initially OFF
Once you press the button something happens
Now the backlight is ON

In this very crude explanation of a backlight, ON and OFF are states. In code, you probably represent that as a variable.

"But what about this mutation thing", you ask.

Well, in imperative/OO code, you are probably used to changing the value of variables. This is what's known as a mutation (i.e. change). Functional Programming strongly discourages mutating state; Instead you create distinct, new states.

Say you have a list of two numbers (or array or whatever) and now you want to add one more. If your list structure were mutable, you might append another number two it. In immutable land, however, you create a new list containing the items from your old list and one more.

The cool thing is you don't even need an inherently immutable list structure, you can just use JavaScript's good old Array type. To make your life easier, TC39 people even threw in Array.prototype.concat.

// Mutable code
let itemList = [1, 2];
mutList.push(3);

// Immutable code
let twoItemList = [1, 2];
let threeItemList = twoItemList.concat(3);

Immutability might seem a little counter-intuitive at first but it is one of the things that will give you the promised testability.

Think about it, itemList might have 2 items at one point of your code and 3 at some other... Your test could be expecting it to have two items but it has three, now you're wondering where in your program life cycle it changed. Maybe you forgot to clear the junk from a previous test? Maybe you changed it on a different method... You have to sit there and figure that out.

On the other hand, twoItemList always has these two items and never changes, so if you are getting a test failed because your function returned 3 items instead of 2, you know what happened. You returned the wrong list 😇.

Side Effects (and pure functions)

Relax, we are not gonna discuss pharmaceuticals.

One of the core tenants of FP is to try and avoid side-effects.

"But, what on earth is a side effect?", you ask.

Glad you asked. A side effect is anything you do that does not involve your own state. Lets get back to this in a bit. But first, functions

Functions

"But I already know everything I need to know about functions", you say.

Do you?

In FP a function (or rather a pure function) is a piece of code that may/may not take something as input (arguments) and returns something and does nothing more. It does not:

Perform some I/O task
Change the state of anything outside its scope
Return different things for the same input

So, getting back to out Side Effects discussion, a side effect is any and all of the above discussed despicable things except the last one.

Or in other words, if a function performs some I/O task instead of or in addition to returning an output, or it changes the global state somehow; it is said to have side effects and is referred to as an impure function*

A function can also be impure if its output is non-deterministic. That is, gives different output for the exact same input.

That's all for today

I feel like the above topics are a good enough indication of how things work in FP. We'll get into more details about how to do certain things in the next article.

Till then, Peace ✌️

Hello, Blog!

Fahad Hossain — Sun, 05 Jan 2020 04:55:32 +0000

Once again, I’ve switched blogging platforms.

I’ve switched between {WordPress, Ghost, Jekyll, Medium, Hexo} and now this is Postach.io (or dev.to)

So...

Hello, World!

Lets try to make a bunch of "Hello, world" programs in as many languages as I can 🙃

Let’s start with my favourite language, JavaScript

console.log("Hello, world")

Or,

document.write('Hello, world')

Onto the next few language

#include <stdio.h>





int main() {

 printf("%s", "Hello, world");

 return 0;

}

C++

#include <iostream>

int main() {

 std::cout << "Hello, world" << std::endl;

 return 0;

}

package main

import "fmt"





func main() {

 fmt.Println("hello world")

}

Back to some concise syntax

Python

print("Hello, world")

Haskell

main::IO()

main = putStrLn "Hello, world"

ReasonML

Js.log("Hello, world");

Now, the piece de resistance,

My least favourite ones

Java

public class HelloWorld {

 public static void main (String[] args) {

 System.out.println("Hello, world");

 }

}

using System;



namespace HelloWorld {

 class Program {

 static void Main(string[] args) {

 Console.WriteLine("Hello, world");

 }

 }

}

PHP

<?php

echo "Hello, world";

That’s about all I could think of. This post is nothing but a test to see what a blog post looks like.

Peace ✌️