In this article, we will look at some of the most commonly used built-in functions in C++ so you can start using them in your code.

What we’ll cover:

1. The sqrt() Function

2. The pow() Function

3. The sort() Function

4. The find() Function

5. The binarysearch() Function

6. The max() Function

7. The min() Function

8. The swap() Function

9. The toupper() Function

10. The tolower() Function

The sqrt() Function

You use the sqrt() function to determine the square root of the value of type double. It is defined inside the <cmath> header file.

Syntax:

sqrt (n)

Parameter: This function takes only one parameter of type double which is a number we want to find the square root of.

Return Type: The square root of the value of type double.

Example Code

Let’s look at an example so you can see how this function works:

// C++ program to see the use of sqrt() function
#include <cmath>     
#include <iostream>  

using namespace std;  
int main()
{
    double x = 100;

    double answer;

    // Use the sqrt() function to calculate the square root of the number
    answer = sqrt(x);

    // Print the result 
    cout << answer << endl;

    return 0;
}

Output:

10

The pow() Function

You use the pow() function to find the value of the given number raised to some power. This function is also defined inside the <cmath> header file.

Syntax:

double pow(double x, double y);

Parameters:

• x: The base number.

• y: The exponential power.

Return Type: value of x raised to the power y.

Example Code:

Let’s look at an example to see how this works:

// C++ program to see the use of the pow() function
#include <cmath>
#include <iostream>
using namespace std;

int main()
{
 // Declare an integer variable 'base' 
    int base = 5;

// Declare an integer variable 'exponent' 
    int exponent = 3;

// pow(5, 3) means 5^3 which is 5*5*5 = 125
// Use the pow() function to calculate base raised to the power of exponent
    int answer = pow(base, exponent);

// output the result
    cout << answer << endl;
}

Output:

125

The sort() Function

The sort() function is part of STL's <algorithm> header. It is a function template that you can use to sort the random access containers, such as vectors, arrays, and so on.

Syntax:

sort (arr , arr + n, comparator)

Parameters:

• arr: The pointer or iterator to the first element of the array.

• arr + n: The pointer to the imaginary element next to the last element of the array.

• comparator: The unary predicate function that is used to sort the value in some specific order. The default value of this sorts the array in ascending order.

Return Value: This function does not return any value.

Example Code:

Let’s look at an example:

#include <iostream>     
#include <algorithm>    // Header file that includes the sort() function

using namespace std;    

int main()
{
    // Declare and initialize an integer array with unsorted elements
    int arr[] = { 13, 15, 12, 14, 11, 16, 18, 17 };

    // Calculate the number of elements in the array
    int n = sizeof(arr) / sizeof(arr[0]);

    // Use the built-in sort() function from the algorithm library
    sort(arr, arr + n);

    // Print the sorted array using a loop
    for (int i = 0; i < n; ++i)
        cout << arr[i] << " ";  

    return 0;
}

Output:

11 12 13 14 15 16 17 18

The find() Function

The find() function is also part of the STL <algorithm> library. You use this function to find a value in the given range. You can use it with both sorted and unsorted datasets as it implements a linear search algorithm.

Syntax:

find(startIterator, endIterator, key)

Parameters:

• startIterator: Iterates to the beginning of the range.

• endIterator: Iterates to the end of the range.

• key: The value to be searched.

Return Value: If the element is found, then the iterator is set to the element. Otherwise, it iterates to the end.

Example Code:

Let’s look at an example to better understand how it works:

// C++ program to see the the use of the find() function

#include <algorithm>   // Required for the find() function
#include <iostream>    
#include <vector>      

using namespace std;   

int main()
{
    // Initialize a vector 
    vector<int> dataset{ 12, 28, 16, 7, 33, 43 };

    // Use the find() function to search for the value 7
    auto index = find(dataset.begin(), dataset.end(), 7);

    // Check if the element was found
    if (index != dataset.end()) {
        // If found, print the position (index) by subtracting the starting iterator
        cout << "The element is found at the "
             << index - dataset.begin() << "nd index";
    }
    else {
        // If not found
        cout << "Element not found";
   }
    return 0;
}

Output:

The element is found at the 3rd index

The binary_search() Function

The binary_search() function is also used to find an element in the range – but this function implements binary search instead of linear search as compared to the find() function. It’s also faster than the find() function, but you can only use it on sorted datasets with random access. It’s defined inside the <algorithm> header file.

Syntax:

binary_search (starting_pointer , ending_pointer , target);

Parameters:

• starting_pointer: Pointer to the start of the range.

• ending_pointer: Pointer to the element after the end of the range.

• target: Value to be searched in the dataset.

Return Value:

• Returns true if the target is found.

• Else return false.

Example Code:

Let’s check out an example to see how it works:

// C++ program for the binary_search() function

#include <algorithm>   
#include <iostream>    
#include <vector>      

using namespace std;   

int main()
{
    // Initialize a sorted vector of integers
    vector<int> arr = { 56, 57, 58, 59, 60, 61, 62 };

    // binary_search() works only on sorted containers
    if (binary_search(arr.begin(), arr.end(), 62)) {
        // If found, print that the element is present
        cout << 62 << " is present in the vector.";
    }
    else {
        // If not found, print that the element is not present
        cout << 16 << " is not present in the vector";
    }

    cout << endl;
}

Output:

62 is present in the vector.

The max() Function

You can use the std::max() function to compare two numbers and find the bigger one between them. It’s also defined inside the <algorithm> header file.

Syntax:

max (a , b)

Parameters:

• a: First number

• b: Second number

Return Value:

• This function returns the larger number between the two numbers a and b.

• If the two numbers are equal, it returns the first number.

Example Code:

Here’s an example:

// max() function

#include <algorithm>  
#include <iostream>   
using namespace std;

int main()
{
    // Declare two integer variables
    int a = 8 ;
    int b = 10 ;

    // Use the max() function to find the larger number between a and b
    int maximum = max(a, b);

    // Display the result with a meaningful message
    cout << "The maximum of " << a << " and " << b << " is: " << maximum << endl;

    return 0;
}

Output:

The maximum of 8 and 10 is: 10

The min() Function

You can use the std::min() function to compare two numbers and find the smaller of the two. It’s also defined inside the <algorithm> header file.

Syntax:

min (a , b)

Parameters:

• a: First number

• b: Second number

Return Value:

• This function returns the smaller number between the two numbers a and b.

• If the two numbers are equal, it returns the first number.

Example Code:

Here’s an example:

// use of the min() function

#include <algorithm>  // For the built-in min() function
#include <iostream>   
using namespace std;

int main()
{
    // Declare two integer variables to store user input
    int a = 4 ;
    int b = 8 ;

    // Use the min() function to find the smaller 
    int smallest = min(a, b);

    // Display the result 
    cout << "The smaller number between " << a << " and " << b << " is: " << smallest << endl;

    return 0;
}

Output:

The smaller number between 4 and 8 is: 4

The swap() Function

The std::swap() function lets you swap two values. It’s defined inside <algorithm> header file.

Syntax:

swap(a , b);

Parameters:

• a: First number

• b: Second number

Return Value: This function does not return any value.

Example:

Here’s how it works:

//  use of the swap() function

#include <algorithm>  // For the built-in swap() function
#include <iostream>   
using namespace std;

int main()
{
    int firstNumber = 8 ;
    int secondNumber = 9 ;


    // Use the built-in swap() function to exchange values
    swap(firstNumber, secondNumber);

    // Display values after swapping
    cout << "After the swap:" << endl;
    cout << firstNumber << " " << secondNumber << endl;

    return 0;
}

Output:

After the swap:

9 8

The tolower() Function

You can use the tolower() function to convert a given alphabet character to lowercase. It’s defined inside the <cctype> header.

Syntax:

tolower (c);

Parameter(s):

• c: The character to be converted.

Return Value:

• Lowercase of the character c.

• Returns c if c is not a letter.

Example Code:

Here’s how it works:

// C++ program

// use of tolower() function

#include <cctype>     
#include <iostream>   
using namespace std;

int main()
{
    // Declare and initialize a string with uppercase characters
    string str = "FRECODECAMP";

    for (auto& a : str) {
        a = tolower(a);
    }

    // Print the modified string 
    cout << str;

    return 0;
}

Output:

freecodecamp

The toupper() Function

You can use the toupper() function to convert the given alphabet character to uppercase. It’s defined inside the <cctype> header.

Syntax:

toupper (c);

Parameters:

• c: The character to be converted.

Return Value

• Uppercase of the character c.

• Returns c if c is not a letter.

Example Code:

Here’s how it works:

// use of toupper() function

#include <cctype>     
#include <iostream>   
using namespace std;

int main()
{
    // Declare and initialize a string 
    string str = "freecodecamp";

    for (auto& a : str) {
        a = toupper(a);
    }

    // Output the converted uppercase string
    cout << str;

    return 0;
}

Output:

FREECODECAMP

Conclusion

Inbuilt functions are helpful tools in competitive programming and in common programming tasks. These help in improving code readability and enhance the efficiency of code. In the above article, we discussed some very useful common inbuilt functions. Some common inbuilt functions are max(), min(), sort(), and sqrt(), etc. By using these inbuilt libraries, we can reduce boilerplate code and speed up the process of software development. These help in writing more concise, reliable, and maintainable C++ programs.

And if you'd like to support me and my work directly so I can keep creating these tutorials, you can do so here. Thank you!

Elixir is based on another language called Erlang. Erlang was developed by Ericsson in the 1980s for telecom applications requiring extreme reliability and availability. It includes built-in support for concurrency, distribution, and fault-tolerance. Elixir, created by José Valim, brings a more approachable and expressive syntax to the Erlang VM. It lowers the barrier to entry for using Erlang's powerful features.

In Elixir, functions are the primary building blocks of programs, similar to how classes and methods are the core units in object-oriented languages. But instead of modeling behavior through stateful objects, functional languages like Elixir treat computation as a series of pure functions that take input and produce output without side effects.

This paradigm offers several benefits:

• Immutability: Data is immutable by default. Once a variable is bound, it can't be changed. This avoids hard to track bugs caused by side effects.

• Functions as first-class citizens: Functions can be assigned to variables, passed as arguments, and returned from other functions. This enables powerful abstractions and code reuse.

• Pattern matching: Elixir uses pattern matching to bind variables, unpack data structures, and control program flow. This leads to concise and declarative code.

• Recursion: Looping is typically achieved through recursion. Elixir optimizes recursive calls to avoid stack overflow issues.

While functional programming requires a shift in thinking, it can lead to more predictable and maintainable systems. Elixir makes this paradigm friendly and accessible.

One of Elixir's standout features is its concurrency model. It uses lightweight processes to achieve massive scalability:

• Processes are isolated and share no memory, communicating only via message passing.

• The Erlang VM can run millions of processes concurrently on a single machine.

• Fault-tolerance is achieved by supervising and restarting failed processes.

This architecture enables building distributed, real-time systems that efficiently use modern multi-core hardware.

An Animated Introduction to Elixir

To make Elixir's functional and concurrent nature more approachable, I developed an interactive tutorial called "An Animated Introduction to Elixir". It uses annotated code playbacks to walk through key language features step-by-step. From basic syntax to advanced topics like concurrency, each concept is explained through code and accompanying visuals.

You can access the free 'book' of code playbacks here: https://playbackpress.com/books/exbook.

For more info about code playbacks, you can watch a short demo:

Part 1 of the book focuses on core Elixir – syntax basics, pattern matching, functions and modules, key data structures like tuples, maps, lists, functional concepts like closures, recursion, enumeration, and efficient immutability.

• 1.1 Hello Elixir!!!

• 1.2 Numbers and the Match Operator

• 1.3 Functions and More Matching

• 1.4 Modules and More Matching with SimpleMath

• 1.5 Closures

• 1.6 Ranges and the Enum Module

• 1.7 Tuples

• 1.8 Maps

• 1.9 SimpleDateFormatter Module with Maps

• 1.10 Lists, Matching, and Recursion

• 1.11 Poker Probabilities

• 1.12 Recursion in Elixir

Part 2 explores Elixir's concurrency model – working with processes, message passing between processes, dividing work across processes, and real-world examples and benchmarking. The concepts are applied to practical problems like estimating poker probabilities and generating calendars.

• 2.1 Adding Tests to the Mix

• 2.2 Process Basics

• 2.3 Prime Sieve

• 2.4 Calendar with Processes

• 2.5 Poker with Processes

Why Learn Elixir?

Learning Elixir is beneficial for programmers for several compelling reasons. Elixir's functional paradigm and immutable data structures promote writing cleaner, more predictable, and maintainable code.

Its actor-based concurrency model, built on the robust Erlang VM, enables developing highly scalable, fault-tolerant, and distributed systems that can efficiently leverage multi-core processors and handle massive numbers of simultaneous users. Also, Elixir has a friendly, expressive syntax that lowers the barrier to entry for using these powerful features.

Finally, Elixir has a rapidly growing, vibrant community and ecosystem. For example, the Elixir ecosystem includes powerful web frameworks like Phoenix for building scalable web applications, Nerves for creating embedded software for devices, and Ecto for writing database queries and interacting with different databases.

If you have any questions or feedback, I'd love to hear it. Comments and feedback are welcome anytime: mark@playbackpress.com.

If you'd like to support my work and help keep Playback Press free for all, consider donating using GitHub Sponsors. I use all of the donations for hosting costs. Your support helps me continue creating educational content like this. Thank you!

You'll need to have some previous programming experience in another language to get the most out of this tutorial. Clojure is so different from most imperative programming languages that it doesn't really matter where you are coming from as long as you know the basics (variables, if statements, loops, and functions).

If you are looking for a complete beginner's guide to programming, you can find some of my other programming content below.

Here, I will cover functions, data structures, immutability, closures, tail recursion, lazy sequences, macros, and concurrency.

Clojure is a functional programming language. In it, the function is king and data is immutable. This may be a different paradigm than you are used to, but there are some compelling reasons to use it. Clojure's immutability is particularly good for programs that need to take advantage of modern hardware on laptops and mobile phones (multiple processors sharing a single memory).

Clojure runs on the JVM. It can be difficult to set up Clojure because it involves installing Java, Leiningen, and sometimes an editor plugin. To make things easier, I recommend starting with a web-based IDE. There is no easier way to start programming in Clojure than using replit. I recommend using it to write your first programs in Clojure. If you feel up to it, check out these docs to get started on your own machine.

Even if you don't use Clojure every day, learning it will change how you think about programming. It will help you understand recursion, higher-order functions, and data transformations in a new way. These ideas transfer well to other languages like JavaScript, Python, or Rust. In short, learning Clojure will make you a better programmer.

Code Playbacks

This material will not be delivered like traditional online tutorials or video series. Each section includes links to interactive code playbacks that visually animate changes made to a program in a step-by-step manner, helping you understand how it was written.

A code playback shows how a program evolves by replaying all the steps in its development. It has an author-supplied narrative, screenshots, whiteboard-style drawings, and self-grading multiple choice questions to make the learning process more dynamic and interactive.

Here's a short YouTube video explaining how to view a code playback:

Playback Press

Playback Press is a platform for sharing interactive code walkthroughs that I created. I’m Mark, by the way, a professor of computer science. These books provide interactive programming lessons through step-by-step animations, AI tutoring, and quizzes.

If you want to see the full Clojure 'book', you can go here:

An Animated Introduction to Clojure, by Mark Mahoney

I also built Storyteller, the free and open-source tool that powers code playbacks.

AI Tutor

When viewing a code playback, you can ask an AI tutor about the code. It answers questions clearly and patiently, making it a helpful resource for learners. You can also ask the AI tutor to generate new self-grading multiple-choice questions to test your knowledge of what you are learning.

To access the AI tutor and self-grading quizzes, simply create a free account on Playback Press and add the book to your bookshelf.

Table of Contents

• Introduction to Clojure

• Functions

• Closures

• Recursion

• Lazy Sequences

• Macros

• Concurrency

Introduction to Clojure

These first few programs show how to print to the screen, perform basic arithmetic, and store some data. Go through each of these now:

• Hello World!!!

• Readers/evaluators and simple arithmetic

• Dog age converter

This program shows how to use the Java capability that it built into to the JVM.

• Java interoperability

These programs show some basic data structures in Clojure and how they are immutable.

• Clojure data structures

• Efficient immutability (more with data structures)

Hands-On Practice

Problem 1

Write a Clojure program that prompts the user for the length and width of a wooden board in inches. Then display the number of whole square feet that are in the board. For example, if the height is 27 inches and the width is 34 inches, then the number of square feet is 6.375.

Problem 2

Write a program that creates an empty list and use def to store a reference to it called empty-list. Use cons to add your name to it and store it in a new list called my-name.

Use conj to add all of your siblings to a list called me-and-my-siblings (if you don't have any or don't have that many you can use some of the Kardashians).

Print all the names in me-and-my-siblings. Then print the third name on the list me-and-my-siblings.

Create a map with all of your siblings' names as keys and their birth years as values. Use assoc to add your name and birth year to the map. Use the map to print everyone's name and their age in the year 2050.

Problem 3

Create a map with the number of days in each of the months called days-in-months. Use Clojure keywords like :jan and :feb as the keys and the number of days in the months as the values.

Create a second map from the first that has 29 days for February. Call this one days-in-months-leapyear. Make sure to do this efficiently, use assoc to create a new value for February. Finally, print each of the maps.

Functions

Next, I'll discuss creating and calling functions in Clojure. Clojure is a functional programming language so this is a pretty important topic.

The first two programs show how to write functions in Clojure.

• Functions in Clojure

• Fizz Buzz

This program shows how to use a map to encapsulate data along with some functions that manipulate the data.

• Maps as objects

These programs show how to read and write to a file using functions.

• Reading from a file (with CS poetry)

• Writing to a file

Hands-On Practice

Problem 1

Write three mathematical functions:

• square squares a passed in parameter

• cube cubes a passed in parameter

• pow raises a base number to an exponent

For this group of functions, do not use any built-in mathematical functions.

Hint: look at the Clojure function repeat and reduce for the pow function. Use the let function to hold temporary values so that they can be referred to later.

Problem 2

Write a function that takes a number and will calculate the factorial value for that number.

5! is 5 * 4 * 3 * 2 * 1 = 120

10! is 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 = 3,628,800

Hint: this type of problem is typically done with recursion. But for now, try to do it without recursion. Look at the Clojure range and reduce functions.

Problem 3

Write a function that determines whether a number is prime or not. Use the range and filter functions to filter out non-primes in a range of values.

Hint: look at the not-any? and mod functions for determining whether a number is prime or not.

Problem 4

Write a function that takes one or more string parameters, converts them to numbers, and then adds them together and returns the sum.

(println (add-strings "10")) ;prints 10

(println (add-strings "10" "20")) ;prints 30

(println (add-strings "10" "20" "30")) ;prints 60

(println (add-strings "10" "20" "30" "40")) ;prints 100

Use Clojure's reduce function or apply to turn the strings into numbers and then add them together.

Closures

A closure is a way to associate data permanently with a function.

The first program shows how to bind data to a function.

• Closures

The second program shows a more complex example of using closures.

• Interest in an account

Hands-On Practice

Problem 1

Write a function that returns a function. The Fibonacci numbers are a sequence of numbers that are generated by summing the previous two numbers together:

0 1 1 2 3 5 8 13 21 34 ...

Usually, the first two numbers are assumed to be 0 and 1. But in this case, return a function that uses the specified first two numbers in the sequence. Then generate and print out the requested numbers in the sequence.

(defn fibs-fn[firstFib secondFib] ...) ;;fill this in

(def another-fib (fibs-fn 10 15)) ;;create a fib function that prints starting with 10 and 15

(another-fib 5) ;;print first 5 fibs: 10 15 25 40 65

Recursion

A recursive function is one that calls itself. Since every function call results in a stack frame being placed on the call stack, regular recursion runs the risk of 'blowing up the call stack'. Tail recursion, with recur, is an efficient way to simulate recursion without the downsides.

• Tail Recursion

• Recursion and Fizz-Buzz

• Recursion and Square Roots

• Converting a String to an Integer in the Bases 2-16

• Mortgage Scheduler

Hands-On Practice

Problem 1

Write a recursive function to reverse the letters of a string.

(reverse-string "Mark Mahoney") ;;returns "yenohaM kraM"

You may need to create a recursive 'helper' function that takes a different number of parameters than the non-recursive function or use the loop form. Make sure you use recursion with the recur form so that you do not 'blow the stack'.

Problem 2

Write a function that will join a series of strings together separated by another string. The function should create and return a new string. Use recursion with recur.

(defn join [separator & parts]
   ;;your code here)

(join ", " "Mark" "Laura" "Buddy" "Patrick" "Willy") ;;"Mark, Laura, Buddy, Patrick, Willy"

Problem 3

Write a function that takes in an integer and converts it to a string. The user can specify the base that the string is in from 2-10. The program should use recursion and recur (either a recursive function or the loop form).

(to-string 100 10) ;;"100" decimal
(to-string 7 2) ;;"111" binary

Lazy Sequences

A lazy sequence defers the cost of creating values until they are needed. The first program shows how to create a lazy sequence. The next two are more concrete examples.

• Lazy sequences

• Lazy Prime Generator (Fizz Buzz part 3)

• Poker Probabilities

Hands-On Practice

Problem 1

Create a function that generates a lazy sequence of squares. For example, (1 4 9 16 ... to infinity). Use it to print the first 10 squared values.

Then write a function that generates a lazy sequence of values raised to a power:

(defn lazy-pow [start-val power]
  ...)

(take 6 (lazy-pow 10 2)) ;(100 121 144 169 196 225)
(take 6 (lazy-pow 10 3)) ;(1000 1331 1728 2197 2744 3375)

Problem 2

Write a function that generates an infinite lazy sequence of possible permutations of the passed in sequence.

(take 3 (lazy-perm ["a" "b" "c"]))
;("a" "b" "c")

(take 12 (lazy-perm ["a" "b" "c"])) 
;("a" "b" "c" "aa" "ab" "ac" "ba" "bb" "bc" "ca" "cb" "cc")

(take 39 (lazy-perm ["a" "b" "c"])) 
;("a" "b" "c" "aa" "ab" "ac" "ba" "bb" "bc" "ca" "cb" "cc" "aaa" "aab" "aac" "aba" "abb" "abc" "aca" "acb" "acc" "baa" "bab" "bac" "bba" "bbb" "bbc" "bca" "bcb" "bcc" "caa" "cab" "cac" "cba" "cbb" "cbc" "cca" "ccb" "ccc")

(take 120 (lazy-perm ["a" "b" "c"]))
;("a" "b" "c" "aa" "ab" "ac" "ba" "bb" "bc" "ca" "cb" "cc" "aaa" "aab" "aac" "aba" "abb" "abc" "aca" "acb" "acc" "baa" "bab" "bac" "bba" "bbb" "bbc" "bca" "bcb" "bcc" "caa" "cab" "cac" "cba" "cbb" "cbc" "cca" "ccb" "ccc" "aaaa" "aaab" "aaac" "aaba" "aabb" "aabc" "aaca" "aacb" "aacc" "abaa" "abab" "abac" "abba" "abbb" "abbc" "abca" "abcb" "abcc" "acaa" "acab" "acac" "acba" "acbb" "acbc" "acca" "accb" "accc" "baaa" "baab" "baac" "baba" "babb" "babc" "baca" "bacb" "bacc" "bbaa" "bbab" "bbac" "bbba" "bbbb" "bbbc" "bbca" "bbcb" "bbcc" "bcaa" "bcab" "bcac" "bcba" "bcbb" "bcbc" "bcca" "bccb" "bccc" "caaa" "caab" "caac" "caba" "cabb" "cabc" "caca" "cacb" "cacc" "cbaa" "cbab" "cbac" "cbba" "cbbb" "cbbc" "cbca" "cbcb" "cbcc" "ccaa" "ccab" "ccac" "ccba" "ccbb" "ccbc" "ccca" "cccb" "cccc")

Macros

A macro specifies some code to be executed, sort of like a function, but it also allows some of that code to be replaced with values that come from the user.

The code in a macro is kind of like a template that can be altered to suit the caller’s needs. With this powerful feature, the language can be expanded to do things that the language inventor never thought to add.

• Macros

• Set macros

Hands-On Practice

Problem 1

Write a macro that takes in a grade earned on a student assignment (on a 0-100 scale) and some code to execute if the grade is a passing or failing.

(defmacro eval-grade [grade if-passing if-failing] ...)

And use it to print or call a function based on the value of the grade

(def users-grade 43)

(eval-grade users-grade (println "Passing") (println "Failing")) ;;"Failing"

(eval-grade users-grade (praise users-grade) (warning users-grade)) ;;call the warning function

Concurrency

Concurrency in Clojure is a big topic. I start by discussing threads. Then I talk about different strategies for dealing with data that is shared among different threads.

• Threads

• Threaded poker

• refs and threads

• Atoms

• Poker with atoms

• Thread logging with agents

• Simpler concurrency

Hands-On Practice

Problem 1

This lab asks you to create a Clojure program that will count how many primes are in a given range.

Create a thread pool and have each thread check a single number in the range. If it finds a prime, it will increase a counter (which should be an atom since it is shared by all of the threads). Look at the program above on Atoms as a starting point.

Conclusion

If you've made it this far, you’ve already taken meaningful steps toward learning a language that can change how you write and think about code.

Clojure offers a fresh perspective on programming, one that focuses on simplicity, immutability, and the power of functions. Learning Clojure will change your brain and you will take these lessons with you to other languages as well.

So keep experimenting, keep asking questions, and keep practicing to sharpen your skills.

Comments and Feedback

You can find all of these code playbacks in the free 'book', An Animated Introduction to Clojure. There are more free books here:

• An Animated Introduction to Programming in C++

• An Animated Introduction to Programming with Python

• Database Design and SQL for Beginners

• Worked SQL Examples

• Programming with SQLite

• An Introduction to Web Development from Back to Front

• An Animated Introduction to Clojure

• An Animated Introduction to Elixir

• A Brief Introduction to Ruby

• Mobile App Development with Dart and Flutter

• OO Design Patterns with Java

• How I Built It: Word Zearch

Comments and feedback are welcome via email: mark@playbackpress.com.

If you'd like to support my work and help keep Playback Press free for all, consider donating using GitHub Sponsors. I use all of the donations for hosting costs. Your support helps me continue creating educational content like this. Thank you!

This article explores how to implement FP concepts in Java, including viewing functions as first-class citizens, chaining, and composing them to create function pipelines.

We'll also discuss the technique of currying, which allows a function that takes multiple arguments to be transformed into a chain of functions that each take a single argument. This can simplify the use of complex functions and make them more reusable.

In this article, I'll show you examples of how to implement these concepts in Java using modern language features, like “java.util.function.Function”, “java.util.function.BiFunction”, and a user-defined TriFunction. We'll then see how to overcome its limitation using currying.

The java.util.function.Function interface

The java.util.function.Function interface is a key component of the Java 8 functional programming API. The java.util.function.Function is a functional interface in Java that takes input of type 'T' and produces an output of type 'R'.

In functional programming, functions are first-class citizens, meaning that they can be passed around as values, stored in variables or data structures, and used as arguments or return values of other functions.

The function interface provides a way to define and manipulate functions in Java code.

The function interface represents a function that takes one input and produces one output. It has a single abstract method, apply(), which takes an argument of a specified type and returns a result of a specified type.

You can use the function interface to define new functions, as well as to manipulate and compose existing functions. For example, you can use it to convert a list of objects of one type to a list of objects of another type, or to apply a series of transformations to a stream of data.

One of the main benefits of the function interface is that it allows you to write code that is more concise and expressive. By defining functions as values and passing them around as arguments or return values, developers can create more modular and reusable code. Also, by using lambdas to define functions, Java code can be more expressive and easier to read.

You can think about java.util.function.Function like this:

Function<A, B>

The java.util.function.BiFunction is also a functional interface in Java that takes two inputs 'T' and 'U' and produces an output of type 'R'. In short, BiFunction takes 2 inputs and returns an output:

BiFunction<Integer, Integer, Integer> sum = (a, b) -> a + b;

You can think about java.util.function.BiFunction like this:

BiFunction<A, B, C>

Function Composition and Chaining

Function chaining is a technique in functional programming that involves composing multiple functions into a single pipeline or chain.

In Java FP, function chaining is often used to transform data in a series of steps, where each step applies a specific transformation to the data and passes it on to the next step in the chain.

The function interface in Java provides a powerful tool for function chaining. Each function in the chain is defined as a separate instance of the Function interface. The output of each function becomes the input to the next function in the chain. This allows for a series of transformations to be applied to the data, one after another, until the final result is produced.

How to use the andThen method

The "andThen()" method is a default method provided by the function interface in Java. This method takes a sequence of two functions and applies them in succession, using the output of the first function as the input to the second function. This chaining of the functions results in a new function that combines the behavior of both functions in a single transformation.

The syntax of andThen looks like this:

default <V> Function<T, V> andThen(Function<? super R, ? extends V> after)

andThen

We can break the example down into series of steps. Initially the "multiply" function will be executed and its output passed as input to the "add" function. Then the "logOutput" function is used to log the resulting output.

public class FunctionChainingExample {

    static Logger logger = Logger.getLogger(FunctionChainingExample.class.getName());

    private static Function<Integer, Integer> multiply = x -> x * 2;

    private static Function<Integer, Integer> add = x -> x + 2;

    private static Function<Integer, Unit> logOutput = x -> {
        logger.info("Data:" + x);
        return Unit.unit();
    };

    public static Unit execute(Integer input) {
        Function<Integer, Unit> pipeline = multiply
                                               .andThen(add)
                                               .andThen(logOutput);
        return pipeline.apply(input);
    }

    public static void main(String[] args) {
        execute(10);
    }

}

The the above code snippet showcases the creation of three functions, namely multiply, add, and logOutput.

The function multiply accepts an integer input and produces an integer output, just like the add function. But, the logOutput function accepts an integer input and returns nothing (as represented by the Unit object, which implies the absence of a value).

The execute function chains the three functions together, where the output of multiply is utilized as the input for the add function, and the resulting output of add is passed to the logOutput function for logging purposes. The above example showcases function chaining using the andThen default method.

How to use the compose method

Unlike the andThen method, the compose method is another default method provided by the function interface in Java. It applies the first function to the output of the second function.

This means that the second function is applied to the input first, and then the first function is applied to the output of the second function. As a result, a chain of functions is created where the output of the second function becomes the input of the first function.

The compose function looks like this:

default  Function<V, R> compose(Function<? super V, ? extends T> before)

compose

When to use andThen vs compose depends on the order in which you want the functions to be applied.

If you want to apply the functions in the order they are defined, from left to right, then you should use the andThen method. This method applies the first function to the input, and then applies the second function to the output of the first function.

This is useful when you want to chain together functions that process the input data in a specific order.

On the other hand, if you want to apply the functions in the opposite order, from right to left, then you should use the compose method. This method applies the second function to the input, and then applies the first function to the output of the second function.

This is useful when you want to chain together functions that need to be applied in the opposite order of the way they are defined.

In general, you should use andThen when you want to apply the functions in the order they are defined, and use compose when you want to apply the functions in the opposite order. But the choice between the two methods ultimately depends on the specific requirements of your use case.

 public static Unit compose(Integer input) {
        Function<Integer, Unit> pipeline = logOutput
                                            .compose(add)
                                            .compose(multiply);
        return pipeline.apply(input);
    }

In the compose example, the functions are executed in a right-to-left order. Firstly, multiply is executed and its output is passed to the add function. Then, the resulting output of the add function is passed to logOutput for logging purposes.

How to use the apply() function

The apply() method takes an input and returns a result. It is used to apply a function to an argument and compute a result.

The apply() function is a method of functional interfaces, such as the function interface, that takes an argument of a specified type and returns a result of a specified type. It is the single abstract method of these interfaces, which is required for them to be used as functional interfaces.

The apply() function defines the behavior of the functional interface. When an instance of a functional interface is created, the apply() function is implemented to define what the functional interface does when it is called with an argument.

Function<Integer, Integer> multiply = x -> x * x;
        int result = multiply.apply(5);

In this code, we define a function called multiply that takes an integer argument and returns the square of that integer. We then call the apply() function on this function, passing in the integer value of 5. The apply() function executes the lambda expression defined in the square Function, and returns the result of the computation, which in this case is 25.

Let's understand by looking at a real-world example, FileReaderPipeline.

public class FileReaderPipeline {

    static Function<String, String> trim = String::trim;
    static Function<String, String> toUpperCase = String::toUpperCase;
    static Function<String, String> replaceSpecialCharacters = 
        str -> str.replaceAll("[^\\p{Alpha}]+", "");

    static Function<String, String> pipeline = 
                                trim
                                  .andThen(toUpperCase)
                                  .andThen(replaceSpecialCharacters);

 public static void main(String[] args) throws IOException {
        try (BufferedReader reader = new BufferedReader(new     FileReader("example.txt"))) {
            String line;
            while ((line = reader.readLine()) != null) {
                String result = pipeline.apply(line);
                System.out.println(result);
            }
        }
    }
}

The above code defines a FileReaderPipeline class, which reads lines from a file, processes them through a pipeline of functions, and prints the resulting output.

First, three functions trim, toUpperCase, and replaceSpecialCharacters are defined using method references and lambda expressions. trim removes leading and trailing whitespace from a String, toUpperCase converts the string to uppercase, and replaceSpecialCharacters removes any non-alphabetic characters from the string.

Next, a function pipeline is created using the andThen method, which chains the three functions together. The input to the pipeline function is a String, and the output is also a String. When a String is passed to the pipeline function, it first removes any leading or trailing whitespace, then converts the string to uppercase, and finally removes any non-alphabetic characters.

Finally, in the main method, the program reads lines from a file (in this example, "example.txt") using a BufferedReader. Each line is processed through the pipeline function using the apply method, which applies each function in the pipeline in sequence, and returns the resulting output. The resulting output is then printed to the console using System.out.println.

Function Currying

The Java util package contains two functional interfaces known as "Function<A, B>" and "BiFunction<A, B, C>". The Function interface takes a single input and produces an output, whereas the BiFunction interface takes two inputs and produces an output. Here is an illustration:

 Function<String, String> toUpper = str -> str.toUpperCase();
 BiFunction<Integer, Integer, Integer> sum = (a, b) -> a + b;

This is a clear constraint as there are only two functions, with one accepting a single input and the other accepting two inputs. Consequently, if we need a function that takes three inputs, we must construct our own customized function.

To this end, let's design a function that accepts three inputs and name it TriFunction. Here is an example implementation:

@FunctionalInterface
public interface TriFunction<A, B, C, O> {
    O apply(A a, B b, C c);

    default <R> TriFunction<A, B, C, O> andThen(TriFunction<A, B, C, O> after) {
        return (A a, B b, C c) -> after.apply(a,b,c);
    }
}

TriFunction<Integer, Integer, Integer, Integer> sum = (a, b, c) -> a + b + c;                                                                
int result = sum.apply(1, 2, 3);

In situations where we require more parameters than what the available functions can accept, we can leverage currying to overcome this limitation.

We can refactor the previous function using currying, which involves decomposing a function that takes multiple arguments into a sequence of functions, each of which accepts only one argument. This is in line with the definition of currying, which is a technique employed in Functional Programming.

Function<Integer, Function<Integer, Function<Integer, Integer>>>     sumWithThreeParams = (a) -> (b) -> (c) -> a + b + c;
                                                                       Function<Integer, Function<Integer, Function<Integer, Function<Integer, Integer>>>> sumWithFourParams = (a)->(b)->(c)->(d) -> a + b + c + d;

The above declares a new Function named sumWithThreeParams that takes an Integer input. It returns a new Function that takes an Integer input and returns yet another new Function that takes an Integer input and returns an Integer output. Similarly a new Function named sumWithFourParams is created.

Note that the curried function sumWithThreeParams and sumWithFourParams allows us to partially apply arguments to the function, which can be useful in situations where we have some of the inputs available but not all of them

Function<Integer, Function<Integer, Integer>> partialSumWithTwoParams                                     = sumWithThreeParams.apply(5);
                                                                        Function<Integer, Integer> partialSumWithOneParams 
                                 = partialSumWithTwoParams.apply(10);

                                                                        int c = 15;
int result = partialSumWithOneParams.apply(c);
System.out.println(result); //30

Conclusion

In this article, we covered the implementation of functional programming (FP) concepts in Java, such as treating functions as first-class citizens, composing them into pipelines, and utilizing currying to simplify complex functions.

We have provided examples using modern language features like java.util.function.Function and java.util.function.BiFunction, as well as a user-defined TriFunction with currying to overcome its limitations.

By applying these techniques, developers can write more concise, reusable, and maintainable code in Java.

With the growing popularity of FP in the industry, understanding and implementing these concepts is becoming increasingly important for Java developers.

After reading this article, if you have found it useful and would like to explore more practical examples, please visit the repository and consider giving it a star.

This tutorial discusses everything you need to know to use JavaScript functions like a pro.

Table of Contents

1. What Is a Function?
2. Why Functions?
3. Syntax of a JavaScript Function
4. What Is a function Keyword?
5. What Is a Function Name?
6. What Is a Parameter?
7. What Is a Code Block?
8. What Is a Function Body?
9. Types of JavaScript Functions
10. What Is a JavaScript Function Declaration?
11. What Is a JavaScript Function Expression?
12. What Is a JavaScript Arrow Function Expression?
13. What Is a JavaScript Immediately Invoked Function Expression?
14. Overview

So, let's get started from the basics.

What Is a Function?

A JavaScript function is an executable piece of code developers use to bundle a block of zero or more statements.

In other words, a function is an executable subprogram (mini-program).

A JavaScript function is a subprogram because its body consists of a series of statements (instructions) to computers—just like a regular program.

The instructions in a function's body can be a variable declaration, return call, console.log() invocation, function definition, or any other JavaScript statements.

Note:

• A program is a list of instructions written for computers to execute.
• Unlike other object types, you can invoke a function without storing it in a variable.
• A JavaScript function is similar to other programming languages' procedures or subroutines.

Why Functions?

Functions provide a way to bundle pieces of code together and reuse them anytime, anywhere, for an unlimited period. This helps you eliminate the burden of writing the same set of code repeatedly.

For instance, alert() is a built-in window function that someone wrote once for all developers to use anytime, anywhere.

Syntax of a JavaScript Function

function nameOfFunction(parameter1, parameter2, ..., parameterX) {
  // function's body
}

A function is composed of five elements:

1. A function keyword
2. The function's name
3. A list of zero or more parameters
4. A code block ({...})
5. The function's body

Let's discuss each element.

What Is a function Keyword?

We use the function keyword to declare to browsers that a specific piece of code is a JavaScript function—not a mathematical or other generic function.

What Is a Function Name?

A function's name allows you to create an identifier for your function, which you can use to reference it.

What Is a Parameter?

A parameter specifies the name you wish to call your function's argument.

A parameter is an optional component of a function. In other words, you do not need to specify a parameter if your function does not accept any argument.

For instance, JavaScript's pop() method is a function without any parameter because it does not accept arguments.

On the other hand, forEach() has two parameters that accept two arguments.

Example of a JavaScript parameter

// Define a function with two parameters:
function myName(firstName, lastName) {
  console.log(`My full name is ${firstName} ${lastName}.`);
}

// Invoke myName function while passing two arguments to its parameters:
myName("Oluwatobi", "Sofela");

// The invocation above will return:
"My full name is Oluwatobi Sofela."

Try it on StackBlitz

The myName() function in the snippet above has two parameters: firstName and lastName.

Suppose you wish to pre-define values for your parameters that browsers can use if users do not invoke the function with the required arguments. In that case, you can create default parameters.

What is a default parameter?

Default parameters allow you to initialize your function's parameters with default values.

For instance, suppose users invoke your function without providing a required argument. In such a case, browsers will set the parameter's value to undefined.

However, default parameters allow you to define the values browsers should use instead of undefined.

Examples of default parameters

Below are examples of how default parameters work in JavaScript.

How to define a function with no default parameters

// Define a function with two parameters:
function myName(firstName, lastName) {
  console.log(`My full name is ${firstName} ${lastName}.`);
}

// Invoke myName function while passing one argument to its parameters:
myName("Oluwatobi");

// The invocation above will return:
"My full name is Oluwatobi undefined."

Try it on StackBlitz

The computer automatically set the lastName parameter to undefined because we did not provide a default value.

How to define a function with an undefined argument and no default parameter

// Define a function with two parameters:
function myName(firstName, lastName) {
  console.log(`My full name is ${firstName} ${lastName}.`);
}

// Invoke myName function while passing two arguments to its parameters:
myName("Oluwatobi", undefined);

// The invocation above will return:
"My full name is Oluwatobi undefined."

Try it on StackBlitz

The computer set the lastName parameter to undefined because we provided undefined as myName()'s second argument.

How to define a function with a default parameter

// Define a function with two parameters:
function myName(firstName, lastName = "Sofela") {
  console.log(`My full name is ${firstName} ${lastName}.`);
}

// Invoke myName function while passing one argument to its parameters:
myName("Oluwatobi");

// The invocation above will return:
"My full name is Oluwatobi Sofela."

Try it on StackBlitz

Instead of undefined, JavaScript used "Sofela" as the lastName parameter's default argument.

How to define a function with an undefined argument and a default parameter

// Define a function with two parameters:
function myName(firstName, lastName = "Sofela") {
  console.log(`My full name is ${firstName} ${lastName}.`);
}

// Invoke myName function while passing two arguments to its parameters:
myName("Oluwatobi", undefined);

// The invocation above will return:
"My full name is Oluwatobi Sofela."

Try it on StackBlitz

Instead of undefined, JavaScript used "Sofela" as the lastName parameter's default argument.

Let's now discuss the fourth element of a JavaScript function: a code block.

What Is a Code Block?

A block is a pair of braces ({...}) used to group multiple statements together.

Here's an example:

{
  const hourNow = new Date().getHours();
}

The block in the snippet above encased one JavaScript statement.

Here's another example:

if (new Date().getHours() < 18) {
  const hourNow = new Date().getHours();
  const minutesNow = new Date().getMinutes();
  console.log(`The time is ${hourNow}:${minutesNow}.`);
}

The if condition's code block grouped three JavaScript statements together.

Now, consider this snippet:

function getTime() {
  const hourNow = new Date().getHours();
  const minutesNow = new Date().getMinutes();
  console.log(`The time is ${hourNow}:${minutesNow}.`);
}

The getTime() function's code block grouped three JavaScript statements. Note that the "function body" is the space inside the function's code block. Let's talk more about it now.

What Is a Function Body?

A function body is where you place a sequence of statements you want to execute.

Syntax of a JavaScript function body

function nameOfFunction() {
  // function's body
}

Function body examples

Below are examples of how we use the function body.

How to define a function with three statements in its body

function getName() {
  const firstName = "Oluwatobi";
  const lastName = "Sofela";
  console.log(firstName + " " + lastName);
}

Try it on StackBlitz

In the snippet above, the function's body contains three statements that the computer will execute whenever the function gets invoked.

Note: console.log() is a method we use to log (write) messages to a web console.

How to define a function with two statements in its body

const bestColors = ["Coral", "Blue", "DeepPink"];

function updateMyBestColors(previousColors, newColor) {
   const mybestColors = [...previousColors, newColor];
   return mybestColors;
}

updateMyBestColors(bestColors, "GreenYellow");

Try it on StackBlitz

In the snippet above, the function's body contains two statements that the computer will execute whenever the function gets invoked.

Note:

• The three dots we prepended to previousColors is called a spread operator. We used it to expand the array argument into individual elements.
• You can also prepend the newColor parameter with a rest operator if you wish to add two or more new colors.
• The return keyword ends its function's execution and returns the specified expression (or undefined if you provide no expression).

So, now that we know the components of a JavaScript function, we can discuss its types.

Types of JavaScript Functions

The four types of JavaScript functions are:

• Function declaration
• Function expression
• Arrow function expression
• Immediately invoking function expression

Let's discuss each type.

What Is a JavaScript Function Declaration?

A function declaration is a function created without assigning it to a variable.

Note: We sometimes call function declaration a "function definition" or "function statement."

Here's an example:

function addNumbers() {
  return 100 + 20;
}

Try it on StackBlitz

The function above is a function declaration because we defined it without storing it in a variable.

What Is a JavaScript Function Expression?

A function expression is a function you create and assign to a variable.

Here's an example:

const myFuncExpr = function addNumbers() {
  return 100 + 20;
};

Try it on StackBlitz

The function above is a named function expression that we assigned to the myFuncExpr variable.

You can also write the snippet above as an anonymous function expression like so:

const myFuncExpr = function() {
  return 100 + 20;
};

Try it on StackBlitz

The function above is an anonymous function expression that we assigned to the myFuncExpr variable.

Note:

• An anonymous function is a function with no name.
• A named function is a function with a name.

A named function's main advantage is that the name makes it easier to trace an error's origin.

In other words, suppose your function threw an error. In such a case, if the function is named, a debugger's stack trace will contain the function's name. Therefore, you will find it easier to identify the error's origin.

What Is a JavaScript Arrow Function Expression?

An arrow function expression is a shorthand way to write a function expression.

Syntax of an arrow function

We define an arrow function with the equality and the greater-than symbols (=>). Here is the syntax:

const variableName = () => {
  // function's body
}

Example of an arrow function

const myFuncExpr = () => {
  return 100 + 20;
};

Try it on StackBlitz

You can see that we defined the function without a function keyword and a function name.

You have to omit the function keyword and function name while writing an arrow function expression. Otherwise, JavaScript will throw a SyntaxError.

Important stuff to know about the JavaScript arrow function expression

Here are three essential facts to remember when using an arrow function expression.

1. The parameters' parentheses are optional

Suppose your arrow function contains only a single parameter. In such a case, you can omit its parentheses.

const myFuncExpr = a => {
  return a + 20;
};

Try it on CodePen

2. The curly brackets and return keyword are optional

Suppose your arrow function contains only a single statement. In that case, you can omit its curly brackets and the return keyword.

const myFuncExpr = (x, y) => x + y;

Try it on StackBlitz

In the snippet above, we implicitly returned the sum of parameters x and y by removing the curly brackets and the return keyword.

Note: Whenever you choose to omit the curly brackets, also make sure that you remove the return keyword. Otherwise, the computer will throw a SyntaxError.

3. Use parentheses to wrap any implicit object return

Suppose you wish to return an object implicitly. In such a case, wrap the object in a grouping operator (...).

For instance, consider the code below:

const myFuncExpr = () => {
  carColor: "White",
  shoeColor: "Yellow",
};

Try it on CodeSandbox

The snippet above will throw a SyntaxError because JavaScript assumed the curly brackets ({}) to be the function body's code block—not an object literal.

Therefore, whenever you wish to return an object literal implicitly–without using the return keyword explicitly–make sure to encase the object literal in a grouping operator.

Here's an example:

const myFuncExpr = () => ({
  carColor: "White",
  shoeColor: "Yellow",
});

Try it on CodeSandbox

Note that you can use the grouping operator to return any single value. For instance, the snippet below grouped the sum of x and 56.

const myFuncExpr = x => (x + 56);

Try it on CodePen

Let's now discuss the fourth type of JavaScript function.

What Is a JavaScript Immediately Invoked Function Expression?

An immediately invoked function expression (IIFE) is a function expression that invokes itself automatically.

Note: We sometimes call an IIFE a "Self-Invoking Function Expression" or "Self-Executing Anonymous Function Expression."

Syntax of an IIFE

(function() {
  /* ... */
})();

An IIFE is composed of three main components:

1. A grouping operator: The first pair of parentheses ()
2. A function: Enclosed within the grouping operator
3. An invocator: The last pair of parentheses ()

Examples

Below are examples of an IIFE.

How to define a named IIFE

(function addNumbers() {
  console.log(100 + 20);
})();

Try it on StackBlitz

The function in the snippet above is a named self-invoking function expression.

How to define an anonymous IIFE

(function() {
  console.log(100 + 20);
})();

Try it on StackBlitz

The function in the snippet above is an anonymous self-invoking function expression.

How to define an arrow function IIFE

(() => console.log(100 + 20))();

Try it on StackBlitz

The function in the snippet above is an arrow self-invoking function expression.

How to define an async IIFE

(async () => console.log(await 100 + 20))();

Try it on StackBlitz

The function in the snippet above is an asynchronous self-invoking function expression.

So, now that we know what an Immediately Invoked Function Expression is, we can discuss how it works.

How does an IIFE work?

By default, the computer does not know what data type code is until it evaluates it.

For instance, suppose you ask the computer to process 4. In such a case, the system won't know if 4 is a number type until it evaluates it.

Therefore, JavaScript will throw a SyntaxError if you use any number method directly on 4.

Here's an example:

// Convert 4 to a string value:
4.toString();

// The invocation above will return:
"Uncaught SyntaxError: Invalid or unexpected token"

Try it on CodeSandbox

The computer threw a SyntaxError because it does not recognize 4 as a number data type.

However, suppose you assign 4 to a variable. In such a case, the computer will first convert it to a number data type before storing it into the variable.

Afterward, JavaScript will allow you to use any number methods on the number variable.

Here's an example:

// Assign 4 to a variable:
const myNum = 4;

// Convert myNum's content to a string value:
myNum.toString();

// The invocation above will return:
"4"

Try it on CodeSandbox

The snippet above did not return any error because JavaScript evaluated myNum as a number data type.

But you don't have to assign 4 to a variable before the computer can evaluate its data type appropriately.

You can alternatively put your value in parentheses to force the computer to evaluate its data type before using it for other things.

For instance, consider this snippet:

// Evaluate 4's data type and turn it into a string value:
(4).toString();

// The invocation above will return:
"4"

Try it on CodeSandbox

The snippet above enclosed 4 in parentheses to make the computer evaluate its data type before using the toString() method to convert it to a string value.

Using parentheses to make JavaScript evaluate your code's data type first is what happens in an Immediately Invoking Function Expression (IIFE).

For instance, consider this example:

// Evaluate the function's data type and immediately invoke it:
(function addNumbers() {
  console.log(100 + 20);
})();

// The invocation above will return:
120

Try it on StackBlitz

The snippet above enclosed the addNumbers function in parentheses to make the computer evaluate its data type before invoking it immediately after the evaluation.

Overview

In this article, we discussed what a JavaScript function object is. We also used examples to see how it works.

Thanks for reading.

And here's a useful ReactJS resource:

I wrote a book about React!

• It's beginner friendly ✔
• It has live code snippets ✔
• It contains scalable projects ✔
• It has plenty of easy-to-grasp examples ✔

The React Explained Clearly book is all you need to understand ReactJS.

I'll try to break it down in pieces and give a simple explanation of each paradigm. This way you can understand what people are talking about when they say "object oriented", "functional" or "declarative".

This will be a superficial and brief theoretical introduction more than anything else, though we're going to see some pseudo-code and code examples too.

I plan to explore each paradigm in depth with practical JavaScript examples in the future, so follow me (links at the bottom) if you're interested in that kind of article. ;)

Let's go!

Table of Contents

• What is a programming paradigm

• What a programming paradigm is not

• Why should I care?

• Popular programming paradigms

  • Imperative programming

  • Procedural programming

  • Functional programming

  • Declarative programming

  • Object-oriented programming

• Roundup

What is a Programming Paradigm?

Programming paradigms are different ways or styles in which a given program or programming language can be organized. Each paradigm consists of certain structures, features, and opinions about how common programming problems should be tackled.

The question of why are there many different programming paradigms is similar to why are there many programming languages. Certain paradigms are better suited for certain types of problems, so it makes sense to use different paradigms for different kinds of projects.

Also, the practices that make up each paradigm have developed through time. Thanks to the advances both in software and hardware, different approaches have come up that didn't exist before.

And last I think, there's human creativity. As a species, we just like creating things, improving what others have built in the past, and adapting tools to our preference or to what seems more efficient to us.

All this results in the fact that today we have many options to choose from when we want to write and structure a given program. 🥸

What a Programming Paradigm is Not

Programming paradigms are not languages or tools. You can't "build" anything with a paradigm. They're more like a set of ideals and guidelines that many people have agreed on, followed, and expanded upon.

Programming languages aren't always tied to a specific paradigm. There are languages that have been built with a certain paradigm in mind and have features that facilitate that kind of programming more than others (Haskel and functional programming is a good example).

But there are also "multi-paradigm" languages, meaning you can adapt your code to fit a certain paradigm or another (JavaScript and Python are good examples).

At the same time, programming paradigms aren't mutually exclusive, in the sense that you could use practices from different paradigms at the same time with no problem at all.

Why should I care?

Short answer: general knowledge.

Long answer: I find that it's interesting to understand the many ways in which programming can be done. Exploring these topics is a good way of opening your mind and helping you think outside the box and outside the tools you already know.

Moreover, these terms are used a lot in the coding world, so having a basic understanding will help you better understand other topics as well.

Popular Programming Paradigms

Now that we have introduced what programming paradigms are and are not, let's go through the most popular ones, explain their main characteristics, and compare them.

Keep in mind this list is not exhaustive. There are other programming paradigms not covered here, although I'll be covering the most popular and most widely-used ones.

Imperative Programming

Imperative programming consists of sets of detailed instructions that are given to the computer to execute in a given order. It's called "imperative" because as programmers we dictate exactly what the computer has to do, in a very specific way.

Imperative programming focuses on describing how a program operates, step by step.

Say you want to bake a cake. Your imperative program to do this might look like this (I'm not a great cook, so don't judge me 😒):

1- Pour flour in a bowl
2- Pour a couple eggs in the same bowl
3- Pour some milk in the same bowl
4- Mix the ingredients
5- Pour the mix in a mold
6- Cook for 35 minutes
7- Let chill

Using an actual code example, let's say we want to filter an array of numbers to only keep the elements bigger than 5. Our imperative code might look like this:

const nums = [1,4,3,6,7,8,9,2]
const result = []

for (let i = 0; i < nums.length; i++) {
    if (nums[i] > 5) result.push(nums[i])
}

console.log(result) // Output: [ 6, 7, 8, 9 ]

See that we're telling the program to iterate through each element in the array, compare the item value with 5, and if the item is bigger than 5, push it into an array.

We're being detailed and specific in our instructions, and that's what imperative programming stands for.

Procedural Programming

Procedural programming is a derivation of imperative programming, adding to it the feature of functions (also known as "procedures" or "subroutines").

In procedural programming, the user is encouraged to subdivide the program execution into functions, as a way of improving modularity and organization.

Following our cake example, procedural programming may look like this:

function pourIngredients() {
    - Pour flour in a bowl
    - Pour a couple eggs in the same bowl
    - Pour some milk in the same bowl
}

function mixAndTransferToMold() {
    - Mix the ingredients
    - Pour the mix in a mold
}

function cookAndLetChill() {
    - Cook for 35 minutes
    - Let chill
}

pourIngredients()
mixAndTransferToMold()
cookAndLetChill()

You can see that, thanks to the implementation of functions, we could just read the three function calls at the end of the file and get a good idea of what our program does.

That simplification and abstraction is one of the benefits of procedural programming. But within the functions, we still got same old imperative code.

Functional Programming

Functional programming takes the concept of functions a little bit further.

In functional programming, functions are treated as first-class citizens, meaning that they can be assigned to variables, passed as arguments, and returned from other functions.

Another key concept is the idea of pure functions. A pure function is one that relies only on its inputs to generate its result. And given the same input, it will always produce the same result. Besides, it produces no side effects (any change outside the function's environment).

With these concepts in mind, functional programming encourages programs written mostly with functions (surprise 😲). It also defends the idea that code modularity and the absence of side effects makes it easier to identify and separate responsibilities within the codebase. This therefore improves the code maintainability.

Going back to the array filtering example, we can see that with the imperative paradigm we might use an external variable to store the function's result, which can be considered a side effect.

const nums = [1,4,3,6,7,8,9,2]
const result = [] // External variable

for (let i = 0; i < nums.length; i++) {
    if (nums[i] > 5) result.push(nums[i])
}

console.log(result) // Output: [ 6, 7, 8, 9 ]

To transform this into functional programming, we could do it like this:

const nums = [1,4,3,6,7,8,9,2]

function filterNums() {
    const result = [] // Internal variable

    for (let i = 0; i < nums.length; i++) {
        if (nums[i] > 5) result.push(nums[i])
    }

    return result
}

console.log(filterNums()) // Output: [ 6, 7, 8, 9 ]

It's almost the same code, but we wrap our iteration within a function, in which we also store the result array. In this way, we can assure the function doesn't modify anything outside its scope. It only creates a variable to process its own information, and once the execution is finished, the variable is gone too.

Declarative Programming

Declarative programming is all about hiding away complexity and bringing programming languages closer to human language and thinking. It's the direct opposite of imperative programming in the sense that the programmer doesn't give instructions about how the computer should execute the task, but rather on what result is needed.

This will be much clearer with an example. Following the same array filtering story, a declarative approach might be:

const nums = [1,4,3,6,7,8,9,2]

console.log(nums.filter(num => num > 5)) // Output: [ 6, 7, 8, 9 ]

See that with the filter function, we're not explicitly telling the computer to iterate over the array or store the values in a separate array. We just say what we want ("filter") and the condition to be met ("num > 5").

What's nice about this is that it's easier to read and comprehend, and often shorter to write. JavaScript's filter, map, reduce and sort functions are good examples of declarative code.

Another good example are modern JS frameworks/libraries like React. Take this code for example:

<button onClick={() => console.log('You clicked me!')}>Click me</button>

Here we have a button element, with an event listener that fires a console.log function when the button is clicked.

JSX syntax (what React uses) mixes HTML and JS in the same thing, which makes it easier and faster to write apps. But that's not what browsers read and execute. React code is later on transpiled into regular HTML and JS, and that's what browsers run in reality.

JSX is declarative, in the sense that its purpose is to give developers a friendlier and more efficient interface to work with.

An important thing to notice about declarative programming is that under the hood, the computer processes this information as imperative code anyway.

Following the array example, the computer still iterates over the array like in a for loop, but as programmers we don't need to code that directly. What declarative programming does is to hide away that complexity from the direct view of the programmer.

Here's a nice comparison between imperative and declarative programming.

Object-Oriented Programming

One of the most popular programming paradigms is object-oriented programming (OOP).

The core concept of OOP is to separate concerns into entities which are coded as objects. Each entity will group a given set of information (properties) and actions (methods) that can be performed by the entity.

OOP makes heavy usage of classes (which are a way of creating new objects starting out from a blueprint or boilerplate that the programmer sets). Objects that are created from a class are called instances.

Following our pseudo-code cooking example, now let's say in our bakery we have a main cook (called Frank) and an assistant cook (called Anthony) and each of them will have certain responsibilities in the baking process. If we used OOP, our program might look like this.

// Create the two classes corresponding to each entity
class Cook {
    constructor constructor (name) {
        this.name = name
    }

    mixAndBake() {
        - Mix the ingredients
        - Pour the mix in a mold
        - Cook for 35 minutes
    }
}

class AssistantCook {
    constructor (name) {
        this.name = name
    }

    pourIngredients() {
        - Pour flour in a bowl
        - Pour a couple eggs in the same bowl
        - Pour some milk in the same bowl
    }

    chillTheCake() {
        - Let chill
    }
}

// Instantiate an object from each class
const Frank = new Cook('Frank')
const Anthony = new AssistantCook('Anthony')

// Call the corresponding methods from each instance
Anthony.pourIngredients()
Frank.mixAndBake()
Anthony.chillTheCake()

What's nice about OOP is that it facilitates the understanding of a program, by the clear separation of concerns and responsibilities.

In this example I've just scratched the surface of the many features of OOP. If you'd like to know more, here are two great videos explaining the basics of OOP:

• OOP video 1

• OOP video 2

And here's a nice comparison between imperative, functional and object-oriented programming.

Roundup

As we've seen, programming paradigms are different ways in which we can face programming problems, and organize our code.

Imperative, procedural, functional, declarative, and object oriented paradigms are some of the most popular and widely used paradigms today. And knowing the basics about them is good for general knowledge and also for better understanding other topics of the coding world.

As always, I hope you enjoyed the article and learned something new. If you want, you can also follow me on linkedin or twitter.

Cheers and see you in the next one! =D

One core difference between these two types of functions is whether or not they have side effects.

In this article, you will learn what side effects are and we'll discuss the differences between pure and impure functions.

Without any further ado, let's get started with side effects.

What is a Side Effect?

A side effect occurs in a program whenever you use external code in your function — which, as a result, impacts the function’s ability to perform its task.

So what exactly does this mean? Let's see with some examples.

Side Effect Example 1: How to add an old value to a new one

let oldDigit = 5;

function addNumber(newValue) {
  return oldDigit += newValue;
}

In the snippet above, oldDigit’s usage within the function gives addNumber() the following side effects:

First side effect: Dependency on oldDigit

The fact that addNumber() depends on oldDigit to successfully perform its duties means that whenever oldDigit is not available (or undefined), addNumber() will return an error.

Second side effect: Modifies external code

As addNumber() is programmed to mutate oldDigit’s state, which implies that addNumber() has a side effect of manipulating some external code.

Third: Becomes a non-deterministic function

Using external code in addNumber() makes it a non-deterministic function — as you can never determine its output by solely reading it.

In other words, to be sure of addNumber()’s return value, you must consider other external factors — such as the current state of oldDigit.

Therefore, addNumber() is not independent — it always has strings attached.

Side Effect Example 2: How to print text to your console

function printName() {
  console.log("My name is Oluwatobi Sofela.");
}

In the snippet above, console.log()’s usage within printName() gives the function side effects.

How does console.log cause a function to have side effects?

A console.log() causes a function to have side effects because it affects the state of external code — that is, the console object's state.

In other words, console.log() instructs the computer to alters the console object's state.

As such, when you use it within a function, it causes that function to:

1. Be dependent on the console object to perform its job effectively.
2. Modify the state of an external code (that is, the console object’s state).
3. Become non-deterministic — as you must now consider the console’s state to be sure of the function’s output.

Therefore, whenever you use external code in your function, that code will cause side effects.

So how do side effects relate to pure and impure functions?

Let’s find out by looking at the definition of a pure function and its impure alternative.

What is an Impure Function?

So now that we know what side effects in functions are, we can talk about impure (and pure) functions.

First, an impure function is a function that contains one or more side effects.

Consider the JavaScript code below:

const myNames = ["Oluwatobi", "Sofela"];

function updateMyName(newName) {
  myNames.push(newName);
  return myNames;
}

In the snippet above, updateMyName() is an impure function because it contains code (myNames) that mutates an external state — which gives updateMyName() some side effects.

What is a Pure Function?

A pure function is a function without any side effects.

Consider the JavaScript code below:

function updateMyName(newName) {
   const myNames = ["Oluwatobi", "Sofela"];
   myNames[myNames.length] = newName;
   return myNames;
}

In the snippet above, notice that updateMyName() does not depend on any external code to accomplish its duties. This makes it a pure function.

Wherever possible, you should use pure functions in your applications. Let's discuss some of the advantages you get by doing so.

Advantages of Pure Functions

The following are some advantages of pure functions.

Pure functions are independent

Pure functions do not affect any external state, and they are also not affected by external code.

In other words, all external data a pure function uses gets received as parameters — they are not explicitly used internally.

Therefore, what you see within is what you get — there are absolutely no strings attached.

As such, you don’t need to look for external conditions (states) that might impact your pure function's effective operation as all activities happen within.

Pure functions are easier to read

Pure functions are easier to read and debug than their impure alternatives.

Pure functions are so readable because they are solely dependent on themselves — they neither affect nor are they impacted by external states.

Important Stuff to Know about Pure Functions

Keep these three essential pieces of info in mind whenever you choose to use pure functions.

You can clone an external state into a pure function

Cloning an external state into a pure function does not make the function impure.

State duplication is simply a copy-and-paste operation that does not leave any strings attached between the source and its clone.

Example:

const myBio = ["Oluwatobi", "Sofela"];

function updateMyBio(newBio, array) {
  const clonedBio = [...array];
  clonedBio[clonedBio.length] = newBio;
  return clonedBio;
}

console.log(updateMyBio("codesweetly.com", myBio));

Try it on StackBlitz

In the snippet above, updateMyBio() used the spread operator to duplicate myBio’s state into clonedBio. However, it is still a pure function because it is neither dependent on myBio nor does it modify any external code.

Instead, it is an exclusively deterministic function programmed to use the cloned version of its array parameter.

Avoid code mutations in pure functions

Technically, you can mutate variables defined locally within a pure function’s scope. However, it is best to avoid doing so.

For instance, consider the code below:

const compBio = ["code", "sweetly"];

function updateCompBio(newBio, array) {
  const clonedBio = [...array];
  clonedBio[clonedBio.length] = newBio;
  return clonedBio;
}

console.log(updateCompBio(".com", compBio));

Try it on StackBlitz

In the snippet above, updateCompBio() is a pure function that uses clonedBio[clonedBio.length] = newBio to alter its local state.

Although such an operation does not make updateCompBio() impure, it is not the best practice.

The recommended way to write a pure function is to make it receive all its values as parameters like so:

const compBio = ["code", "sweetly"];

function updateCompBio(newBio, array) {
  return [...array, newBio];
}

console.log(updateCompBio(".com", compBio));

Try it on StackBlitz

Notice how clean and portable our code now looks. This is an advantage of making your pure function receive all its values as parameters. By so doing, you will also find it easier to debug your code.

The same input will always return the same output

A vital trait about pure functions is that they will always return the same value with the same set of inputs — no matter how many times you invoke them.

Wrapping it up

Your function is pure if it does not contain any external code. Otherwise, it is impure if it includes one or more side effects.

In this article we discussed what pure and impure functions are, and we learned about the advantages using pure functions can bring to your code.

Thanks for reading!

Imagine that you are on a football team. After practice, the team loves to go out together and eat.

Let's say that the team usually wants to eat pizza or burgers. However, you want the whole team to go out to the same place after practice because it is more fun that way.

Therefore, you need to get the team to agree on the football field where everyone is going – getting burgers or pizza.

But there is one problem: the coach went home early. Everyone is exhausted and hungry after the practice, so they got easily distracted and want to come to a decision fast.

Moreover, you cannot yell at the football field because the entire team tends to talk really loudly, and your suggestion might be easily overwritten by another person.

You must be thinking, "There is only one way that I can achieve this agreement – through person-to-person communication, and want everyone to achieve a consensus."

How are you going to solve this?

This analogy is the same problem that we encounter in distributed systems, but you are dealing with many servers this time. We want to make many servers agree on common events or common information in an asynchronous environment.

You can use many algorithms to solve the problems, and today we will talk about one of them: the Paxos Algorithm.

Paxos is one of the earliest published papers about this distributed consensus algorithm that runs rounds and rounds of times to help many servers agree on a value proposed by a group member.

The algorithm uses peer-to-peer communication, where each peer can be in three roles, the proposer, the acceptor, and the learner. These roles don't have to be separated on each server – meaning a server can have the role of the learner, the acceptor, and the proposer at the same time.

Going back to the Football analogy above, for simplicity, we separate the three roles. Half the team can be the proposer, a quarter can be the acceptor, and a quarter can be the learner.

The proposer can propose where they want to go eat to the acceptor. The acceptor will have some criteria to determine based on each proposed value which place they will choose. Once the acceptor chooses the majority of the proposed messages, they will send it to the learner.

For instance, one of the acceptors elects a burger. They tell the learner that the majority of the team wants to eat burger. However, this is where it gets interesting: another acceptor elects a pizza, and they tell the learner that the majority of the team wants to eat pizza.

Therefore, it is up to the learner to announce based on the message they receive from all the acceptors what the majority really wants to eat. The algorithm will keep running multiple iterations until the learner announces the consensus.

I will explain the Paxos algorithm later in this article in more detail along with its implementation. By the end of this article, you will know how a replication state machine in a distributed system really works and the main algorithm used in the Chubby protocol.

Before we start

In this article, we won't discuss the "why" and the steps the algorithm goes through to reach consensus. If you are interested in why the Paxos Algorithm works, you can look at a great brief introduction in this Google Tech Talk.

Secondly, I assume that the proof and the theory works, and this article will be mainly about the implementation.

A Brief Introduction to the Paxos Algorithm

There are 3 roles in the Paxos algorithm – the proposer, the acceptors, and the learner.

The proposer will propose a value by sending messages to another member of the group.

Acceptors will accept the proposed value.

The learner learns whether the group has reached consensus in a particular round of the algorithm.

The Paxos Algorithm takes in two phases (the prepare phase and accept phase) as follows:

The Prepare Phase

Each group's proposers select a proposal number and send a prepared request to the system's acceptor. The message doesn't need to be received by all of them. It just needs to be the majority (a quorum) for the algorithm to proceed.

The acceptor who receives this message will make a comparison with the current highest proposal number. If the incoming request is higher than the proposal number, it will accept and sends a hopeful message back saying to the proposal, "okay, your proposal is higher than what I currently have, so I will choose you."

If the acceptor already accepts a message, it will send the same thing, except it will say, "okay, your proposal is higher than what I currently have. However, I have already accepted a message proposal. I'm going to attach that proposal number and value in the message too."

If the acceptor receives the message with a lower proposal number, it will simply ignore it.

The Accept Phase

If the proposer receives a majority's promise response, it will check if any promised messages have an accepted message. If it has an accept message, the proposal will accept the message to send the accept request to the processor again.

Suppose the proposer doesn't receive responses from most acceptors to which it broadcasts its message. In that case, it will simply assume that "my proposal number is not high enough, I'm going to create a higher proposal number and broadcast it again to the acceptor."

If the proposer receives responses from the majority of the acceptors, it will inform the learner that it has reached a consensus.

Suppose an acceptor receives an accept request with the proposal number equal to its promises. In that case, it will send back a confirmation to that proposer that the proposal value is accepted.

If an acceptor receives an accept request with the proposal number less than the prepared request, it simply ignores it.

On the learner side, once it receives the majority (quorum) of value coming from the proposal, it will mark that it has reached a consensus.

In theory, it sounds simple. However, in practice, it has lots of cases that need to be accounted for. A couple of papers talk about their experience in implementing Paxos in their production systems.

I saw many sources implement Paxos based on an object-oriented language, such as the Java implementation or implementation with the actor system. So I thought, "why not try to implement one in functional programming terms?"

Please note that this implementation is based on the Paxos-made simple algorithm paper. It doesn't have any fancy invariant such as an account for machine failure, leader election, and so on. This implementation also implements a single-round basic Paxos algorithm.

The Challenge

Model Construction

The essence of the Paxos algorithm is communication between nodes. Therefore, it will be the most intuitive to model the role as objects.

Since it mentions how proposers, acceptors, and learners interact, an actor system is the easiest way to create the algorithm. We can have 3 actors and encapsulate the logic and state within the actors.

Immutable State Management

This can be a challenge if we want to implement something immutable by nature because the algorithm requires a constant change in the internal state.
Object-oriented programming can encapsulate the state management for proposers, acceptors, and learners. On each of these phases, we can mutate the state inside each instance.
For instance, an acceptors instance can have a max_id as a mutable internal state, and it can change the max_id if it receives a prepared message that contains a higher id number.

How to Implement the Paxos Algorithm Functionally

Let's discuss how to implement the Paxos algorithm functionally, and how to design that implementation. I will use Scala and leverage the cats' data library to not reinvent the wheel of creating its own monad instances and its law.

Domain Models

Let's start with each of the domain models. The simplest way to do this is to visualize what the proposer, acceptor, and learner needs.

Proposer Model

The proposer will consist of a value, a proposal number, and a quorum size. The proposal number needs to be unique and in increasing number. The common way to implement this proposal number is an id with a machine-id to ensure uniqueness.

The compare statement is equivalent to a Java comparator where you can check if one is equal to another.

The quorum size is the number of nodes in the system.

Acceptor Model

The acceptor consists of a promise proposal number and the proposal number and value it accepts. Since those two values might not exist, let's make them optional.

Learner Model

The learner needs to keep track of all the accepted responses that it receives and check if the incoming value is over the majority. Therefore, it needs to have a key-value mapping to keep track of those counts.

The key will be the accepted value, and the value will be the number of counts. To know the majority, it needs to have the quorum size. Also, there needs to be a way to chose a value when it is above the majority.

Therefore, the learner will have a quorum size, a mapping for accepted values so far, and the final value that is chosen.

Usually, in OOP, we will put the functions inside the model, and its function will mutate the state of the model.

Functionally, I decided to separate the functions into their own object, Ops, that can interact with the proposer. These separate the model and the operation so that we separate the concerns on state mutation.

Messages

Next, we will think about the message type to communicate for each two-phase algorithm. There are four message types total:

• messagePreapre
• messagePromise
• messageAccept
• messageAccepted

Let's combine these messages as a sealed trait.

Since an acceptor possibly has not accepted any proposal when responding to a promise request, we will use an Option type to embed the AcceptedValue in the Accept message.

Action

One of the benefits of implementing Paxos or any other consensus algorithm in pure functions is that we start thinking of putting all the side effects IO in one component.

There are many ways to push IO's boundary to the end of the world. However, one easy way to do this is to change the statement into a value.

Therefore, we will define an Action type in the implementation. This Action type will be a value type that describes any impure side effects required by the protocol.

For instance, in Paxos, the protocol's side effect sends messages to other machines and processes. Therefore, this action type contains Broadcast and Send, which will broadcast the proposer either the acceptor group or the learner group.

Therefore the Action co-product will have something like this:

How to Create a Pure Message Handling Logic

Once we separate the algorithm's impure effects, we can focus on the algorithm's core state management.

How do we manage to have state management without mutation?

One way to do this is that each function will be wrapped in a State monad. A state monad is a monad that takes in the previous state, and it returns a new state with some results.

If you are not familiar with it, check out my previous blog post about state monads here.

Therefore, we can have a function that has a wrapper of State[Proposer, Action], which translates to Proposer => (Proposer,Action).

To simplify the design, I created three Ops objects – ProposerOps, AcceptorOps, and LearnerOps – to simplify the implementation's design.

This kind of design is influenced by how the actor system or object-oriented way of implementing the algorithm separates each of the operations inside the role's object. The code is more modular and clean this way.

Each of the function operations inside the Ops object class will do the action to mutate the role.

For instance, let's take a look at the prepare phase on the acceptor. The acceptor receives the PrepareMessage and evaluates if the proposalId is the current max proposalId seen so far.

If the proposalId is the max proposalId seen so far, it will reply back with a PromiseMessage. If the value is less than the current max id, it will ignore it.

Therefore, most of the functions will have function definitions like this:

With this, the algorithm's core logic becomes stateless – it doesn't really care about each machine's internal state and process.

We have created pure state management. This makes testing and debugging the Paxos algorithm easier. The important part here is that the Action method can be carried out by some other functions outside of the Paxos Algorithm to call those side effect calls.

In Closing

We just implemented a Paxos algorithm in a pure Functional style. This can be quite hard to implement because the algorithm in the paper is a stateful algorithm. You need to keep track of each state to reach a consensus.

Nevertheless, we take the approach to separate all algorithms into two logics – the impure functionality and core state management.

Separating the IO and the core state management logic in the algorithm is the biggest advantage to make the algorithm testable even in the concurrent environment.

Further, we make each message handling logic as stateless as possible – each call can finish without consulting any internal states of each machine or process.

Lastly, constructing all your algebra and all the messages that it needs at the beginning really helps shape implementing the algorithm itself.

The rest of the code implementation is in this GitHub here.

If you are interested to learn more about the Paxos algorithm and implementation, you can check out these resources:

• scala-composable-paxos/Learner.scala at master · cocagne/scala-composable-paxos · GitHub
• Understanding Paxos
• Paxos in Haskell

Thanks for reading! If you enjoyed this post, feel free to subscribe to my newsletter for more posts like it.

Functional programming is not a new approach to coding, but it has grown in popularity in recent years.

This is because, once programmers understand the basics behind the technique (and are able to write clean and reliable code using it), applications written using a functional approach are much easier to work with.

Because of this, it’s worth gaining an understanding of functional programming once you’ve worked through this JavaScript beginners’ handbook.

If you are frequently working with JavaScript, using this approach can save you time, and can make your code easier to work with and potentially more secure.

In this article, we’ll look at the basic principles of functional programming, and then outline a few of the key tools for using this approach in JavaScript.

Imperative vs. functional programming

The origins of functional programming go way back to the 1930’s with the invention of Lambda Calculus.

This was an approach to computation that sought to define common tasks and functions not as the structural manipulation of data structures (such as arrays and lists), but rather as mathematical functions performed on them.

Image Source

This may sound quite abstract, especially if you are new to programming. But in fact the difference between a functional and imperative approach can be expressed quite succinctly by using an example. Take a look at these:

Imperative:

const arr = [1, 2, 3, 4, 5, 6, 7, 8, 9];

function getOdds(arr) {
  let odds = [];
  for (let i = 0; i < arr.length + 1; i++) {
    if (i % 2 !== 0) {
      odds.push(i);
    }
  }
  return odds;
}

console.log(getOdds(arr)); // logs [1, 3, 5, 7, 9]

Functional:

function getOdds2(arr){
return arr.filter(num => num % 2 !== 0)
}console.log(getOdds2(arr))
// logs [ 1, 3, 5, 7, 9 ]
const getOdds3 = arr => arr.filter(num => num % 2 !== 0)console.log(getOdds3(arr))
// logs [ 1, 3, 5, 7, 9 ]

As you can see, the way in which these programs work is quite different.

The imperative approach is to define a data structure, and then manipulate it in order to obtain the output we need. In a functional approach, we use filter functions to define a programmed function, and then invoke this as needed.

Of course, much of the complexity of how functional programming works is hidden from the end user, and also from the programmer if they are using a front end development framework.

But the advantages of using a functional approach are clear even from this example – this paradigm results in shorter code that is more easily read, understood, and audited.

Why use functional programming?

In addition to this basic advantage, there are a number of other advantages to using functional programming.

Many of these stem from the simple fact that functional code is easier to read than imperatively defined code. Because a human can easily see how a functional program works, rather than having to pull apart the code in order to understand it, many aspects of testing are simplified.

Functional Programming ensures code integrity with penetration testing

Penetration testing becomes more effective where code is human readable. This makes it easier to assess the integrity of functional code.

According to software developer Barbara Ericson of Cloud Defense, penetration testing should always be carried out on JavaScript applications, and a functional approach can help to make this more rigorous.

This ease of reading also simplifies many of the other managerial processes that apply to the development of new code and applications.

In functional approaches, compliance processes are much easier, because programmers shouldn’t worry as much about the execution of their code. This means that the parts of a program that deal with sensitive data can be isolated and evaluated separately from the rest of a program.

Functional Programming makes code easier to read

The advantages of functional approaches are not just limited to the assessment of code, though. They also extend to the process of developing it.

In fact, functional approaches build on and amplify the advantages and disadvantages of JavaScript itself.

Image Source

By making code easier to read, you can bring many more staff groups into the development process, even if they don't have an extensive understanding of JavaScript.

This is a key tenet of the DevOps approach, one that can help mitigate vulnerabilities in your JavaScript code. It's also one that is facilitated by taking a functional approach to your coding.

Key tools for functional programming

There are a number of key tools and concepts that you should be aware of when it comes to actually putting functional approaches into action. Let’s take a look at them.

1. Pure and impure functions

At the most basic level, a functional approach seeks to manipulate data without mutating them. This means that a “functional function” will take data, perform some calculations, and return a result (and all without re-writing any part of the data structure itself).

Functions that work in this way are called “pure” functions, and those that do not are called “impure”.

function getSquare(items) {
  var len = items.length;
  for (var i = 0; i < len; i++) {
    items[i] = items[i] * items[i];
  }
  return items;
}

The general idea here is to leave the data you are working with completely untouched.

If you want to merge two arrays, you should not utilize the Array.prototype.push() strategy (which will overwrite the original data). Instead, use the Array.prototype.concat() function, which will create a new, “working” array for you to work with.

2. Anonymous functions

Anonymous functions are also an important part of functional programming, and one that has its roots in Lambda Calculus.

Anonymous functions, as their name suggests, do not have an explicitly defined name. Instead, they are functions that are assigned to variables, and invoked via them.

 alert((function(x) {
    return !(x > 1)
      ? 1
      : arguments.callee(x - 1) * x;
  })(20));

The advantage of doing this is that as long as you are able to keep track of which functions are assigned to which variables, they can be invoked very easily, and passed from one module to another with nothing more than a variable call. This gives you a powerful, flexible new way of working with functions.

3. Recursive functions

The use of recursive functions is another mark of functional programming. Though the general idea of recursion will be familiar to even beginner programmers, functional programming takes the idea even further by defining functions that call themselves.

function countDown(fromNumber) {
    console.log(fromNumber);

    let nextNumber = fromNumber - 1;

    if (nextNumber > 0) {
        countDown(nextNumber);
    }
}
countDown(3);

This makes the implementation of recursion much simpler – largely because programmers don’t need to use loops to do this.

However, it also comes with dangers. Specifically, having a function call itself makes it much easier for infinite loops to be accidentally created, and so take care to underpin every recursive function with a rigorous way of stopping execution.

Conclusion

Though these three concepts are typical of functional programming, in truth the range of ways in which the paradigm can be applied means that it is more of a philosophy than a set of well-designed tools and processes.

Take a few steps into the exciting world of functional programming, and you’ll start to see its influence everywhere. In fact, it informs many of the most common JavaScript practices in use today.

In other words, although functional programming appears simple on the surface, it has profound consequences on the way that you code. This is why it’s worth learning, even if you don’t use it all the time.

These paradigms exist because they solve problems that programmers face, and they have their own rules and instructions to help you write better code.

Each paradigm helps you solve a specific problem. So it's helpful to have an overview of each of them. We'll cover functional programming here.

At the end of this article, there are some resources you can use to go further if you enjoyed this introduction.

There's also a GitHub glossary that'll help you decode some of the jargon that functional programming uses.

Lastly, you'll find a place to get your hands dirty coding with practical examples and a GitHub repo full of resources you can use to learn more. So let's dive in.

Declarative vs Imperative Programming Paradigms

One example of these paradigms I talked about at the beginning is object-orientated programming. Another is functional programming.

So what exactly is functional programming?

Functional programming is a sub-paradigm of the Declarative programming paradigm, with its own rules to follow when writing code.

What is the declarative programming paradigm?

If you're coding in a language that follows the declarative paradigm, you write code that specifies what you want to do, without saying how.

A super simple example of this is either SQL or HTML:

SELECT * FROM customers

<div></div>

In the above code examples, you aren't implementing the SELECT or how to render a div. You are just telling the computer what to do, without the how.

From this paradigm, there are sub-paradigms such as Functional programming. More on that below.

What is the imperative programming paradigm?

If you're coding in a language that follows the imperative/procedural paradigm, you write code that tells how to do something.

For example, if you do something like below:

for (let i = 0; i < arr.length; i++) {
     increment += arr[i];
}

You are telling the computer exactly what to do. Iterate through the array called arr, and then increment each of the items in the array.

Declarative vs Imperative programming

You can write JavaScript in the Declarative paradigm or the Imperative paradigm. This is what people mean when they say it's a multi-paradigm language. It's just that functional code follows the Declarative paradigm.

If it helps you remember, an example of a declarative command would be to ask the computer to make you a cup of tea (I don't care how you do it, just bring me some tea).

Whilst imperatively, you would have to say:

• Go to the kitchen.
• If there is a kettle in the room, and it has enough water for a cup of tea, turn on the kettle.
• If there is a kettle in the room, and it doesn't have enough water for a cup of tea, fill the kettle with enough water for a cup of tea, then turn on the kettle.
• And so on

So what is Functional Programming?

So what does this mean for functional code?

Because it's a sub-paradigm from the Declarative paradigm, this affects the way you write functional code. It generally leads to less code, because JavaScript already has a lot of the in-built functions you commonly need. This is one reason people like functional code.

It also allows you to abstract away a lot (you don't have to understand in depth how something gets done), you just call a function that does it for you.

And what are the rules that lead to functional code?

Functional programming can be simply explained by following these 2 laws in your code:

1. You architect your software out of pure, isolated functions
2. You avoid mutability and side-effects

Let's dig into that.

1. Architect your software out of pure, isolated functions

Let's start at the beginning,

Functional code makes heavy use of a few things:

Pure functions

The same input always gives the same output (idempotence), and has no side effects.

An idempotent function, is one that, when you reapply the results to that function again, doesn't produce a different result.

/// Example of some Math.abs uses
Math.abs('-1');     // 1
Math.abs(-1);       // 1
Math.abs(null);     // 0


Math.abs(Math.abs(Math.abs('-1')));           // Still returns 1
Math.abs(Math.abs(Math.abs(Math.abs('-1')))); // Still returns 1

Side effects are when your code interacts with (reads or writes to) external mutable state.

External mutable state is literally anything outside the function that would change the data in your program. Set a function? Set a Boolean on an object? Delete properties on an object? All changes to state outside your function.

function setAvailability(){
    available = true;
}

Isolated functions

There is no dependence on the state of the program, which includes global variables that are subject to change.

We will discuss this further, but anything that you need should be passed into the function as an argument. This makes your dependencies (things that the function needs to do its job) much clearer to see, and more discoverable.

Ok, so why do you do things this way?

I know this seems like lots of restrictions that make your code unnecessarily hard. But they aren't restrictions, they are guidelines that try to stop you from falling into patterns that commonly lead to bugs.

When you aren't changing your code execution, forking your code with if 's based on Boolean's state, being set by multiple places in your code, you make the code more predictable and it's easier to reason about what's happening.

When you follow the functional paradigm, you'll find that the execution order of your code doesn't matter as much.

This has quite a few benefits – one being, for example, that to replicate a bug you don't need to know exactly what each Boolean and Object's state was before you run your functions. As long as you have a call stack (you know what function is running/has run before you) it can replicate the bugs, and solve them more easily.

Reusability through Higher order functions

Functions that can be assigned to a variable, passed into another function, or returned from another function just like any other normal value, are called first class functions.

In JavaScript, all functions are first class functions. Functions that have a first class status allow us to create higher order functions.

A higher order function is a function that either take a function as an argument, returns a function, or both! You can use higher order functions to stop repeating yourself in your code.

Something like this:

// Here's a non-functional example
const ages = [12,32,32,53]
for (var i=0; i < ages.length; i++) {
    finalAge += ages[i];
}

// Here's a functional example
const ages = [12,32,32,53]
const totalAge = ages.reduce( function(firstAge, secondAge){
    return firstAge + secondAge;
})

The in-built JavaScript Array functions .map, .reduce, and .filter all accept a function. They are excellent examples of higher order functions, as they iterate over an array and call the function they received for each item in the array.

So you could do:

// Here's an example of each
const array = [1, 2, 3];

const mappedArray = array.map(function(element){
    return element + 1;
});
// mappedArray is [2, 3, 4]

const reduced = array.reduce(function(firstElement, secondElement){
    return firstElement + secondElement;
});
// reduced is 6

const filteredArray = array.filter(function(element){
    return element !== 1;
});
// filteredArray is [2, 3]

Passing the results of functions into other functions, or even passing the functions themselves, in is extremely common in functional code. I included this brief explanation because of how often it is used.

These functions are also often used because they don't change the underlying function (no state change) but operate on a copy of the array.

2. Avoid mutability and side-effects

The second rule is to avoid mutability – we touched on this briefly earlier, when we talked about limiting changes to external mutable state – and side effects.

But here we'll expand further. Basically, it boils down to this: don't change things! Once you've made it, it is immutable (unchanging over time).

var ages = [12,32,32,53]
ages[1] = 12;  // no!
ages = [];     // no!
ages.push("2") // no!

If something has to change for your data structures, make changes to a copy.

const ages = [12,32,32,53]
const newAges = ages.map(function (age){
    if (age == 12) { return 20; }
    else { return age; }
})

Can you see I made a copy with my necessary changes?

This element is repeated over and over again. Don't change state!

If we follow that rule, we will make heavy use of const so we know things wont change. But it has to go further than that. How about the below?

const changingObject = {
    willChange: 10
}

changingObject.willChange = 10;  // no!
delete obj.willChange            // no!

The properties of changingObject should be locked down completely. const will only protect you from initializing over the variable.

const obj = Object.freeze({
    cantChange: 'Locked' }) // The `freeze` function enforces immutability.

obj.cantChange = 0      // Doesn't change the obj!
delete obj.cantChange   // Doesn't change the obj!
obj.addProp = "Gotcha!" // Doesn't change the obj!

If we can't change the state of global variables, then we need to ensure:

• We declare function arguments – any computation inside a function depends only on the arguments, and not on any global object or variable.
• We don't alter a variable or object – create new variables and objects and return them if need be from a function.

Make your code referentially transparent

When you follow the rule of never changing state, your code becomes referentially transparent. That is, your function calls can be replaced with the values that they represent without affecting the result.

As a simple example of checking if your code is referentially transparent, look at the below code snippet:

const greetAuthor = function(){
    return 'Hi Kealan'
}

You should be able to just swap that function call with the string it returns, and have no problems.

Functional programming with referentially transparent expressions makes you start to think about your code differently if you're used to object orientation.

But why?

Because instead of objects and mutable state in your code, you start to have pure functions, with no state change. You understand very clearly what you are expecting your function to return (as it never changes, when normally it might return different data types depending on state outside the function).

It can help you understand the flow better, understand what a function is doing just by skimming it, and be more rigorous with each function's responsibilities to come up with better decoupled systems.

You can learn more about referential transparency here.

Don't iterate

Hopefully, if you've paid attention so far, you see we aren't changing state. So just to be clear for loops go out the window:

for(let i = 0; i < arr.length; i++) {
    total += arr[i];
}

Because we are changing a variable's state there. Use the map higher order function instead.

More Features of Functional Programming

I hope at this point you have a good overview of what functional code is and isn't. But there's some final concepts used heavily in functional code that we have to cover.

In all the functional code I have read, these concepts and tools are used the most, and we have to cover them to get our foundational knowledge.

So here we go.

Recursion in Functional Programming

It's possible in JavaScript to call a function from the function itself.

So what we could always do:

function recurse(){
    recurse();
}

The problem with this is that it isn't useful. It will run eventually until it crashes your browser. But the idea of recursion is a function calling itself from its function body. So let's see a more useful example:

function recurse(start, end){
    if (start == end) {
        console.log(end)
        return;
    } else {
        console.log(start)
        return recurse(start+1, end)
    }
}

recurse(1, 10);
// 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

This code snippet will count from the start argument to the end argument. And it does so by calling its own function again.

So the order of this will look something like this:

A call stack example for this recursive function.

Add a debugger inside the if blocks to follow this if it doesn't make sense to you. Recursion is one tool you can use to iterate in functional programming.

What makes the first example and the second example different? The second one has what we call "a base case". A base case lets the function eventually stop calling into itself infinitely. When start is equal to end we can stop recursing. As we know we have counted to the very end of our loop.

But each call of the functions is calling into its own function again, and adding on to the function argument.

The code example I just included for the counting example isn't a pure function. Why is that?

Because the console is state! And we logged string's to it.

This has been a brief introduction to recursion, but feel free to go here to learn more here.

Why use recursion?

Recursion allows us to stop mutating state variables, for one.

There are also certain data structures (tree structures) that are more efficient when solved with recursion. They generally require less code, so some coders like the readability of recursion.

Currying in Functional Programming

Currying is another tool used heavily in functional code. The arity of a function refers to how many arguments it receives.

// Let's talk arity
function arity2(arg1, arg2){}             // Function has an arity of 2
function arity0(){}                       // Function has an arity of 0
function arity2(arg1, arg2, arg3, arg4){} // Function has an arity of 4

Currying a function turns a function that has an arity of more than 1, to 1. It does this by returning an inner function to take the next argument. Here's an example:

function add(firstNum, secondNum){
    return firstNum + secondNum;
}

// Lets curry this function

function curryAdd(firstNum){
    return function(secondNum){
            return firstNum + secondNum;
    }
}

Essentially, it restructures a function so it takes one argument, but it then returns another function to take the next argument, as many times as it needs to.

Why use currying?

The big benefit of currying is when you need to re-use the same function multiple times but only change one (or fewer) of the parameters. So you can save the first function call, something like this:

function curryAdd(firstNum){
    return function(secondNum){
            return firstNum + secondNum;
    }
}

let add10 = curryAdd(10);
add10(2); // Returns 12

let add20 = curryAdd(20);
add20(2); // Returns 22

Currying can also make your code easier to refactor. You don't have to change multiple places where you are passing in the wrong function arguments – just the one place, where you bound the first function call to the wrong argument.

It's also helpful if you can't supply all the arguments to a function at one time. You can just return the first function to call the inner function when you have all the arguments later.

Partial application in Functional Programming

Similarly, partial application means that you apply a few arguments to a function at a time and return another function that is applied to more arguments. Here's the best example I found from the MDN docs:

const module = {
  height: 42,
  getComputedHeight: function(height) {
    return this.height + height;
  }
};

const unboundGetComputedHeight = module.getComputedHeight;
console.log(unboundGetComputedHeight(32)); // The function gets invoked at the global scope
// outputs: NaN
// Outputs NaN as this.height is undefined (on scope of window) so does 
// undefined + 32 which returns NaN

const boundGetComputedHeight = unboundGetComputedHeight.bind(module);
console.log(boundGetComputedHeight(32));
// expected output: 74

bind is the best example of a partial application. Why?

Because we return an inner function that gets assigned to boundGetComputedHeight that gets called, with the this scope correctly set up and a new argument passed in later. We didn't assign all the arguments at once, but instead we returned a function to accept the rest of the arguments.

Why use partial application?

You can use partial application whenever you can't pass all your arguments at once, but can return functions from higher order functions to deal with the rest of the arguments.

Function composition in Functional Programming

The final topic that I think is fundamental to functional code is function composition.

Function composition allows us to take two or more functions and turn them into one function that does exactly what the two functions (or more) do.

// If we have these two functions

function add10(num) {
    return num + 10;
}
function add100(num) {
    return num + 100;
}

// We can compose these two down to =>
function composed(num){
    return add10(add100(num));
}

composed(1) // Returns 111

You can take this further and create functions to compose any number of multiple arity functions together if you need that for your use case.

Why use function composition?

Composition allows you to structure your code out of re-usable functions, to stop repeating yourself. You can start to treat functions like small building blocks you can combine together to achieve a more complicated output.

These then become the "units" or the computation power in your programs. They're lots of small functions that work generically, all composed into larger functions to do the "real" work.

It's a powerful way of architecting your code, and keeps you from creating huge functions copied and pasted with tiny differences between them.

It can also help you test when your code is not tightly coupled. And it makes your code more reusable. You can just change the composition of your functions or add more tiny functions into the composition, rather than having all the code copied and pasted all over the codebase (for when you need it to do something similar but not quite the same as another function).

The example below is made trivial to help you understand, but I hope you see the power of function composition.

/// So here's an example where we have to copy and paste it
function add50(num) {
    return num + 50;
}

// Ok. Now we need to add 30. But we still ALSO need elsewhere to add 50 still
// So we need a new function
function add30(num){
    return num + 30;
}

// Ugh, business change again
function add20(num){
    return num + 20;
}

// Everytime we need to change the function ever so slightly. We need a new function

//Let's use composition

// Our small, reusable pure function
function add10(num){
    return num + 10;
}

function add50Composed(num){
    return add10(add10(add10(add10(addNum(num)))));
}

function add30Composed(num){
    return add10(add10(add10(num)));
}

function add20Composed(num){
    return add10(add10(num));
}

Do you see how we composed new functions out of smaller, pure functions?

Conclusion

This article covered a lot. But I hope it has explained functional code simply, along with some of the repeating patterns you will see over and over again, in functional and even non-functional code.

Functional code isn't necessarily the best, and neither is object orientated code. Functional code is generally used for more math-based problems like data analysis. It's also very useful for high-availability real-time systems, like stuff written in Erlang (a functional language). But it genuinely does depend problem to problem.

I post my articles on Twitter. If you enjoyed this article you can read more there.

How to learn more

Start here, with freeCodeCamp's introduction to functional programming with JavaScript.

Look here for some libraries you can include and play around with, to really master functional programming.

Peruse this good overview of lots of functional concepts.

Finally, here's an excellent jargon-busting glossary of functional terms.

As a coding instructor, it’s my duty to send programmers out into the world thinking in new ways. A major shift in thinking occurs when we switch from imperative to declarative programming.

Once my students have learned basic JavaScript, we go over functional programming and the array methods used in a declarative coding style. This is where their brains start to pop and sizzle and melt like marshmallows over a fire.

What is Imperative Programming?

As a beginner, you've probably mostly coded in an imperative style: you give the computer a set of instructions to follow and the computer does what you want in an easy-to-follow sequence.

Imagine we have a list of the world’s most commonly-used passwords:

const passwords = [
   "123456",
   "password",
   "admin",
   "freecodecamp",
   "mypassword123",
];

Our app is going to check the user’s password on sign up and not allow them to create a password that is from this list.

But before we do that, we want to refine this list. We already have code that doesn’t allow the user to sign up with a password less than 9 characters long. So we can reduce this list to just passwords that are 9 characters or more to speed up our check.

Imperatively, we would write:

// using the passwords constant from above

let longPasswords = [];
for (let i = 0; i < passwords.length; i++) {
   const password = passwords[i];
   if (password.length >= 9) {
      longPasswords.push(password);
   }
}

console.log(longPasswords); // logs ["freecodecamp", "mypassword123"];

1. We create an empty list called longPasswords.
2. Then we write a loop that will run as many times as there are passwords in the original passwords list.
3. Then we get the password at the index of the loop iteration we are presently on.
4. Then we check if that password is greater than or equal to 9 characters long.
5. If it is, we put it into the longPasswords list.

One of imperative programming’s strengths is the fact that it is easy to reason about. Like a computer, we can follow along step by step.

What is Declarative Programming?

But there's another way of thinking about coding – as a process of constantly defining what things are. This is referred to as declarative programming.

Imperative and declarative programming achieve the same goals. They are just different ways of thinking about code. They have their benefits and drawbacks and there are times to use both.

Though imperative programming is easier to reason about for beginners, declarative programming allows us to write more readable code that reflects what exactly we want to see. Combined with good variable names, it can be a powerful tool.

So instead of giving the computer step by step instructions, we declare what it is we want and we assign this to the result of some process.

// using the passwords constant from above

const longPasswords = passwords.filter(password => password.length >= 9);

console.log(longPasswords); // logs ["freecodecamp", "mypassword123"];

The list of longPasswords is defined (or declared) as the list of passwords filtered for only passwords greater than or equal to 9 characters.

The functional programming methods in JavaScript enable us to cleanly declare things.

• This is a list of passwords.
• This is a list of only long passwords. (After running filter.)
• This is a list of passwords with ids. (After running map.)
• This is a single password. (After running find.)

One of declarative programming’s strengths is that it forces us to ask what we want first. It is in the naming of these new things that our code becomes expressive and explicit.

And when our fellow developers come along and look at our code, they can find bugs more easily:

“You call this variable ‘index’ which makes me expect a number, but I see it is the result of filter which returns an array. What’s up with that?”

I encourage learners to write declarative code as often as possible, constantly defining (and refactoring to redefine) what things are.

Rather than hold an entire imperative process in your head, you can hold a more tangible thing in your head with a clear definition.

Mike Zetlow is the Lead Instructor at 10x Code Camp.

One of the hardest things you have to do in programming is control complexity. Without careful consideration, a program's size and complexity can grow to the point where it confuses even the creator of the program.

In fact, as one author put it:

"The art of programming is the skill of controlling complexity" - Marijn Haverbeke

In this article we will break down a major programming concept. This programming concept can help you keep complexity under control and write better programs.

By the end of this article, you will know what functional programming is, the types of functions there are, the principles of functional programming, and have a deeper understanding of Higher Order functions.

I assume that you already have pre-existing knowledge of the basics of functions. The fundamental concepts of functions will not be covered in this article.

If you want a quick review of functions in JavaScript, then I've written a detailed article here.

What is Functional Programming?

Functional programming is a programming paradigm or style of programming that relies heavily on the use of pure and isolated functions.

Just as you might have guessed from the name, the use of functions is the main component of functional programming. But, merely using functions doesn't translate to functional programming.

In functional programming, we use pure functions, which are functions that don't have side effects. I will explain what all of this means.

Before diving deeper into the article, let us understand some of the terminology and types of functions there are.

Types of Functions

There are four main types of functions.

First Class Functions

In JavaScript all functions are first class functions. That means they can be treated like any other variable.

First class functions are functions that can be assigned as values to variables, returned from other functions, and passed as arguments to other functions.

Consider this example of a function passed to a variable:

const helloWorld = () => {
    console.log("Hello, World"); // Hello, World
};
helloWorld();

Callback Functions

Callback functions are functions that are passed into other functions as arguments and are called by the function in which they are passed.

Simply, callback functions are functions that we write as arguments in other functions. We can't invoke callback functions. They are invoked when the main function in which they were passed as arguments is called.

Let's look at an example:

const testValue = (value, test) => {
    if (test(value)) {
        return `${value} passed the test`;
    } else 
        return `${value} did not pass the test`;
};
const checkString = testValue('Twitter',  string  =>  typeof  string === 'string');
checkString; // Twitter passed the test

testValue is a function that accepts a value and a callback function test which returns "value passed the test" if the value returns true when passed into the callback function.

In this case, the callback function is the second argument we passed into the testValue function. It is invoked when the testValue function is called.

Higher Order Functions

Higher order functions are functions that receive other functions as arguments or return a function.

In this article, am going to further elaborate on higher order functions and why they are such a powerful provision. For now, all you need to know is that these types of functions receive other functions as arguments or return functions.

Asynchronous Functions

Asynchronous functions are functions that don't have a name and cannot be reused. These functions are normally written when we need to carry out something once and in only one place.

A perfect example of an asynchronous function is what we wrote earlier in the article.

const checkString = testValue('Twitter',  value  =>  typeof  value === 'string');
checkString;

// Refer to previous code snippet

checkString is a variable whose value is a function. We pass two arguments into this function.

'Twitter' is the first argument and the second is an asynchronous function. This function has no one name and has only one task: to check whether the given value is a string.

Principles of Functional Programming

Earlier in the article I alluded to the fact that merely using functions does not translate to functional programming.

There are some principles we need to understand if our programs are to qualify for the functional programming standard. Let's look at those.

Avoid Mutations and Side effects.

The first principle of functional programming is to avoid changing things. A function should not change anything such as a global variable.

This is very important because changes often lead to bugs. If a function changes a global variable, for example, it might lead to unexpected behavior in all the places where that variable is used.

The second principle is that a function must be pure, meaning it has no side effects. In functional programming, changes that are made are called mutations, and the outcomes are called side effects.

A pure function does neither of the two. A pure function will always have the same output for the same input.

If a function depends on a global variable, that variable should be passed to the function as an argument. This allows us to obtain the same output for the same input.

Here is an example:

const legalAgeInTheUS = 21;
const checkLegalStatus = (age, legalAge) => {
    return age >= legalAge ? 'Of legal age.' : 'Not of legal age.';
};
const johnStatus = checkLegalStatus(18, legalAgeInTheUS);
johnStatus; // Not of legal age
legalAgeInTheUS; // 21

Abstraction

Abstractions hide details and allow us to talk about problems at a higher level without describing all the implementation details of the problem.

We use abstractions in all almost all aspects of our lives, especially in speech.

For example, instead of saying "I'm going to exchange money for a machine that once plugged in displays moving images accompanied with sound", you are most likely to say "I'm going to buy a television".

In this case buy and television are abstractions. These forms of abstractions make speech a lot more easier and reduce the chances of saying the wrong thing.

But you'll agree with me that before using abstract terms like buy you need to first understand the meaning of the term and the problem it abstracts.

Functions allow us to achieve something similar. We can create functions for tasks that we are most likely to repeat again and again. Functions allows us to create our own abstractions.

On top of creating our own abstractions, some functions have already been created for us to abstract tasks that we are most likely to do time and again.

So we are going to look at some of these higher order functions that already exist to abstract repetitive tasks.

Filtering Arrays

When working with data structures like arrays, we are most likely to find ourselves in a situation where we are only interested in certain items in the array.

To obtain these items we can easily create a function to do the task:

function filterArray(array, test) {
    const filteredArray = [];
    for (let item of array) {
        if (test(item)) {
            filteredArray.push(item);
        }
    }
    return filteredArray;
};
const mixedArray = [1, true, null, "Hello", undefined, "World", false];
const onlyStrings = filterArray(mixedArray, item => typeof item === 'string');
onlyStrings; // ['Hello', 'World']

filterArray is a function that accepts an array and a callback function. It loops through the array and adds the items that pass the test in the callback function into an array called filteredArray.

Using this function we are able to filter an array and return items that we're interested in, such as in the case of mixedArray.

Imagine if we had 10 different programs and in each program we needed to filter an array. Sooner or later it would become extremely tiresome to rewrite the same function over and over again.

Luckily someone already thought about this. Arrays have a standard filter method. It returns a new array with the items in the array it receives that pass the test that we provide.

const mixedArray = [1, true, null, "Hello", undefined, "World", false];
const stringArray = mixedArray.filter(item => typeof item === 'string')
stringArray; // ['Hello', 'World']

Using the standard filter method we were able to achieve the same results we did when we defined our own function in the previous example. So, the filter method is an abstraction of the first function we wrote.

Transforming Array Items With Map

Imagine another scenario where we have an array of items but we would like to perform a certain operation on all the items. We can write a function to do this for us:

function transformArray(array, test) {
    const transformedArray = [];
    for (let item of array) {
        transformedArray.push(test(item));
    }
    return transformedArray;
};
const ages = [12, 15, 21, 19, 32];
const doubleAges = transformArray(ages, age => age * 2);
doubleAges; // [24, 30, 42, 38, 64];

Just like that we have created a function that loops through any given array and transforms all the items in the array based on the callback function the we provide.

But again this would grow tedious if we had to rewrite the function in 20 different programs.

Again, someone thought about this for us, and luckily arrays have a standard method called map which does the same exact thing. It applies the callback function on all the items in the given array and then it returns a new array.

const ages = [12, 15, 21, 19, 32];
const doubleAges = ages.map(age => age * 2);
doubleAges; // [24, 30, 42, 38, 64];

Reducing Arrays with Reduce

Here's another scenario: You have an array of numbers, but you would like to compute the sum of all these numbers and return it. Of course you can write a function to do this for you.

function reduceArray(array, test, start) {
    let sum = start;
    for (let item of array) {
        sum = test(sum, item)
    }
    return sum;
}
let numbers = [5, 10, 20];
let doubleNumbers = reduceArray(numbers, (a, b) => a + b, 0);
doubleNumbers; // 35

Similar to the previous examples we just looked at, arrays have a standard reduce method that has the same logic as the function we just wrote above.

The reduce method is used to reduce an array to a single value based on the callback function that we provide. It also takes an optional second argument which specifies where we want the operation in the callback to start from.

The callback function we provide in the reduce function has two parameters. The first parameter is the first item in the array by default. Otherwise it is the second argument we provide into the reduce method. The second parameter is the current item in the array.

let numbers = [5, 10, 20];
let doubleNumbers = numbers.reduce((a, b) => a + b, 10);
doubleNumbers;  // 45

//The above example uses the reduce method to add all the items in the array starting from 10.

Other Useful Array Methods

Array.some()

All arrays have the some method which accepts a callback function. It returns true if any element in the array passes the test given in the callback function. Otherwise it returns false:

const numbers = [12, 34, 75, 23, 16, 63]
console.log(numbers.some(item => item < 100)) // true

Array.every()

The every method is the opposite of the some method. It also accepts a callback function and returns true if all the items in the array pass the test given in the callback function. Otherwise it returns false:

const numbers = [12, 34, 75, 23, 16, 63]
console.log(numbers.every(item => item < 100)) // true

Array.concat()

The concat method, short for concatenate, is a standard array method that concatenates or joins two arrays and returns a new array:

const array1 = ['one', 'two', 'three'];
const array2 = ['four', 'five', 'six'];
const array3 = array1.concat(array2);
array3; // [ 'one', 'two', 'three', 'four', 'five', 'six' ]

Array.slice()

The slice method is an array method which copies the items of an array from a given index and returns a new array with the copied items. The slice method accepts two arguments.

The first argument receives the index from which to begin copying. The second argument receives the index from which to stop copying. It returns a new array with the copied items from the starting index (exclusive) to the final index (inclusive).

Note however that the slice method does not use zero indexing. So the index of the first array item is 1 not 0:

const numbers = [1,2,3,4,5,7,8];
console.log(theArray.slice(1, 4)); // [ 2, 3, 4 ]

Conclusion

I hope you enjoyed reading this article and learned something new at the same time.

There are lots of array and string methods that I didn't mention in the article. If you wish, take some time to do some research on those methods.

If you would like to connect with me or to just say hi? feel free to do so via Twitter . I also share interesting tips and resources for developers. ?

In this post, I will lay down the major principles of Functional Programming, starting with the basics and then exploring more advanced concepts.

I'll first talk about why you should bother with Functional Programming, that is when it's useful and when it's not.

We will cover a lot of stuff here, so please go at your own pace. Take some breaks and naps between your reading sessions and do the exercises I propose.

Of course, you can skip sections or go back and fourth depending on your needs.

This post intentionally targets several kind of readers:

1. Those who know almost nothing about FP but are pretty familiar with JavaScript
2. Those with an Intermediate knowledge of FP and some familiarity with the paradigm, but who want a clearer picture of the whole and want to explore advanced concepts
3. Those who know a lot about FP and want a cheatsheet+ to revisit some concepts if needed

I invite you to ponder each sentence carefully instead of rushing through the content like we're all used to.

I hope this post will be an important milestone in your journey into Functional Programming, as well as a source of information to go back to when needed.

Just a heads up, though – this post doesn't constitute a single source of truth but rather an invitation to go further after reading it.

In other words, it's meant to be revisited and expanded with further resources and practice.

I hope to clarify the functional landscape in your mind, spark your interest for what you didn't know, and more importantly, provide useful tools for your day-to-day projects.

Without further ado, let's get started!

Why Functional Programming?

In my opinion, there are 3 major benefits to FP and 3 (little) drawbacks:

Advantages:

1. More readability, thus maintainability
2. Less buggy, especially in concurrent contexts
3. A new way of thinking about problem solving
4. (Personal bonus) Just great to learn about!

Drawbacks:

1. Can have performance issues
2. Less intuitive to work with when dealing with state and I/O
3. Unfamiliar for most people + math terminology that slows the learning process

Now I'll explain why I think that.

Increased Readability

First, Functional Programming is often more readable because of its declarative nature.

In other words, the code is focused on describing the outcome of the computations, not the computations themselves.

Kyle Simpson phrases it like this:

Declarative code is code that's more focused on describing the "what" outcome. Imperative code (the opposite) is focused on precisely instructing the computer "how" to do something.

Because we spend the vast majority of our time reading code (around 80% of the time I guess) and not writing it, readability is the first thing we should enhance in order to increase our efficiency when programming.

It's also very likely that you'll return back to a project after several weeks of not touching it, so all the context loaded in your short-term memory will have disappeared.

Thus, understanding your imperative code will not be as easy as it was.

The same thing goes for the potential colleagues that work with you on the project.

So readability is a huge advantage for an ever more important purpose: maintainability.

I could stop arguing right there. Increased readability should give you major motivation to learn Functional Programming.

Luckily, that's an advantage that you'll experience more and more as you get familiar with the paradigm.

No need to be an expert. The moment you write a declarative line of code you'll experience it.

Now the second argument.

Less buggy code

Functional programs are less buggy, especially in concurrent contexts.

Because the functional style strives to avoid mutations, shared resources will not have unexpected contents.

For example, imagine that 2 threads access the same variable.

If this variable can be mutated, then, as the programs grow, you'll likely not get what you want when re-accessing it.

In addition, the rise of multiprocessor systems allows multiple threads to execute in parallel.

So now there's also a risk of overlapping (one thread may try to write while the other tries to read).

It's kind of a shame not to leverage the hardware because we're not able to make the software work.

However, JavaScript is single-threaded and my personal experience doesn't expand much beyond it.

Thus, I'm less confident in this argument, but more experienced programmers seem to agree on that fact (for what I've heard/read).

Problem solving

Finally, the last advantage – and more important than you might think – is that Functional Programming gives you a new way of thinking about problem solving.

You might be so used to solving problems using classes and objects (Object-Oriented Programming) that you don't even think there might be a better way to do so.

I'm not saying that Functional Programming is always better.

I'm saying that it will be better in certain cases and that having this knowledge will (re)open your mind and make you a better programmer.

Because now you'll have more tools and an increased capacity to choose the right one for the problem at hand.

I even think that some core principles in FP can translate to problem solving outside the domain of computers.

Let's see the drawbacks now.

Performance issues

The first is that, by applying FP techniques, you can end up using a lot of time and/or memory.

Because you don't want to mutate things, the process is basically to copy the data, then mutate that copy and use it as the current state.

This means that the original data is left untouched but you allocate a bunch of time and memory to make the new copy.

So when you make a lot of copies (really big nested objects) or use techniques like recursion (accumulating layers in the callstack), performance issues may appear.

However, many solutions exist (structural sharing, tail-call optimization) which make poor performance very rare.

Less intuitive

The second drawback is when you need state or I/O operations.

Well, you're gonna say:

Computers are stateful machines! And eventually I'll need to call my database, or display something on the screen, or write a file.

I totally agree.

The thing is to remember that Functional Programming is a style convenient for humans, but machines make imperative operations (aka mutations) all the time.

That's just how it works at the lowest level.

The computer is in one state at a given moment and it changes all the time.

The point of FP is to ease our reasoning about the code which increases the chances that the messy stuff that comes out of it actually works.

And Functional Reactive Programming helps us deal with state (if you want to learn more, there are links at the end of the post).

Even if imperative code seems easier/more intuitive at first sight, you'll eventually lose track. I'm pretty confident that if you make the initial efforts of learning FP, it will pay off.

For I/O – short for Input/Output, that is code that transfers data to or from a computer and to or from a peripheral device – we can't have pure isolated functions anymore.

To deal with that, we can take a Functional Core Imperative Shell approach.

In other words, we want to do as much as we can in a functional way and push back the I/O operations to the outer layer of the program:

Steeper learning curve

Finally, the last drawback is that Functional Programming is kind of cluttered with math terminology. This often creates unnecessary friction when developers are trying to learn it.

It's likely because this style of programming first appeared in the academic world and stayed there a long time before emerging and becoming more popular.

However, these technical/unfamiliar terms shouldn't make you neglect the very powerful mathematical principles that underlie them.

All in all, I think the strengths of FP outweigh the weaknesses.

And functional programming makes a lot of sense for the majority of general-purpose JavaScript programming.

Just keep in mind that there are few programs with peculiar requirements for which FP is not a good fit. But if that's not your case, there's no reason not to leverage this paradigm.

Now, if you're a total beginner you might be feeling a bit lost. It's ok – bear with me. The following sections will clarify the concepts I referred to here.

Now let's dive into the nuts and bolts of functional programming.

Data, Calculations, and Actions

In FP, you can break down your program in 3 parts: data, calculations and actions.

Data

The data is, well, the data. In our languages, they have different forms, different types.

In JavaScript you have numbers, strings, arrays, objects, and so on. But at the end of the day, they are just bits.

Data are the building blocks of the program. Having none of it is like having no water in an aquatic park.

Then we can do things with the data: calculations or actions.

Calculations

Calculations are mathematical-like transformations of the data.

Functions are a way to create them. You provide it a set of inputs and it returns you a set of outputs.

That's it.

It does nothing outside the function, like in math. The world around the function is not impacted.

In addition, if you feed the function with the same input multiple times, it should always give you the same output.

A common term for this type of function is pure function.

Because of its characteristics, its entire behavior is known in advance. In fact, because it just returns a value, we can treat it as that value, as data.

In other words, we could replace the function call by the value it returns and it would not change the state of the program.

This is called referential transparency. Thus, they're really easy to reason about, and you can use them as function input or output and assign them to variables.

These kinds of functions are called first-class functions. In JavaScript, all functions are first-class.

It's safe to use pure functions because, again, they're like values.

For functions that do more than return a value, you rely on human memory. That's a bad strategy, especially for large software with multiple people working on it.

So you can use pure functions as a replacement for calculations. They are identical.

Now let's talk about actions.

Actions

Of course, we also need functions that impact the outside world, that actually do something. Otherwise, your program would be a calculator without screen.

When a function impacts things outside of itself, we say that it has side-effects. As opposed to pure functions, it is said to be impure.

Common side-effects are assignments/mutations of variables outside the function, logging to the console, making an API call, and so on.

So basically, actions and impure functions are the same.

Here's a simple example to illustrate these concepts:

// ↓ variable
//      ↓ data
let a = 3;

// Calculation / Pure function
const double = (x) => x * 2;

double(a);
// 6

// Action / Impure function
const IncThenPrint = () => {
  // assignment of a variable outside the scope of the function
  a = a + 1;

  // do something (here printing) outside the function
  console.log(a);
};

IncThenPrint();
// console: 4

Data, calculations, and actions in functional programming

In FP, the objective is to separate the data, the calculations, and the actions while striving to do most of the job with calculations.

Why? Because actions rely on the outside world. We don't have total control on it.

Thus, we may get unexpected results/behaviors out of it. So if the majority of your program is made of actions, it quickly becomes a mess.

Taking the previous example, what if somewhere else in the program, someone decided to assign an object to the variable a ?

Well, we'll get an unexpected result when running IncThenPrint because it makes no sense to add 1 to an object:

let a = 3;

// ...
a = { key: "value" };
// ...

// Action / Impure function
const IncThenPrint = () => {
  // assignment of a variable outside the scope of the function
  a = a + 1;

  // do something (here printing) outside the function
  console.log(a);
  // prints: 4
};

IncThenPrint();
// prints: [object Object]1
// (Because JavaScript is a dynamically-typed language, it converts both operands of the + operator
// to strings so it can perform the operation, thus explaining the result.
// But obviously, that not what was intended.)

The ability to differentiate data, calculations, and actions in your program is a fundamental skill to develop.

Mapping

Mapping is a fairly trivial but very important concept in the world of functional programming.

"Mapping from A to B" means going from A to B via some association.

In other words, A points to B by means of some linkage between them.

For example, a pure function maps an input to an output. We can write it like this: input --> output; where the arrow indicates a function.

Another example are objects in JavaScript. They map keys to values.

In other languages, this data structure is often called a "map" or "hash-map", which is more explanatory.

Like the latter term infers, the thing that happens behind the scene is that each key is linked to its value via a hash function. The key is passed to the hash function which returns the index of the corresponding value in the array that stores them all.

Without going into further detail, I wanted to introduce this term because I'll use it throughout this article.

More on side-effects

Before we move on, I want to go deeper into side-effects in JavaScript and showcase a vicious pitfall that you may not be aware of.

To remind ourselves, saying that a function has side-effects is the same as saying, "When this function runs, something outside of its scope will change."

Like I said, it can be logging to the console, making an API call, changing an outer variable, etc.

Let's see an example of the latter:

let y;

const f = (x) => {
  y = x * x;
};

f(5);
y; // 25

That's pretty easy to grasp.

When f runs, it assigns a new value to the outer variable y, which is a side-effect.

A pure version of this example would be:

const f = (x) => x * x;

const y = f(5);
// 25

But there's another way to change an outer variable that's more subtle:

let myArr = [1, 2, 3, { key: "value" }, "a string", 4];

const g = (arr) => {
  let total = 0;

  for (let i = 0; i < arr.length; i++) {
    if (Number.isNaN(Number(arr[i]))) {
      arr[i] = 0;
    }
    total += arr[i];
  }

  return total;
};

g(myArr);
// 10
myArr;
// [1, 2, 3, 0, 0, 4]
// Oops, all elements that were not numbers have been changed to 0 !

Why is that?

In JavaScript, when assigning a value to a variable or passing it to a function, it's automatically copied.

But there's a distinction to make here.

Primitive values (null, undefined, strings, numbers, booleans and symbols) are always assigned/passed by value-copy.

In contrast, compound values like objects, arrays and functions (by the way, arrays and functions are objects in JavaScript, but I don't refer to them as objects for clarity) create a copy by reference on assignment or passing.

So in the previous example, the value passed to g is a compound one, the array myArr.

What happens is that g stores the memory address of myArr in arr, the parameter's name used in the function's body.

In other words, there's no value-copy of each elements in myArr like you would expect. Thus, when you manipulate or change arr, it actually goes to myArr memory's location and perform whatever computation you specified.

So yeah, be aware of that quirk.

Exercises (Set 1)

1. In the snippet below, find the pure functions and the impure ones:

// a
const capitalizeFirst = (str) => str.charAt(0).toUpperCase() + str.slice(1);

// b
const greeting = (persons) => {
  persons.forEach((person) => {
    const fullname = `${capitalizeFirst(person.firstname)} ${capitalizeFirst(
      person.lastname
    )}`;

    console.log(`Hello ${fullname} !`);
  });
};

// c
const getLabels = async (endpoint) => {
  const res = await fetch("https://my-database-api/" + endpoint);
  const data = await res.json();
  return data.labels;
};

// d
const counter = (start, end) => {
  return start === end
    ? "End"
    : // e
      () => counter(start + 1, end);
};

2. Convert this snippet into a pure one (you can make more than one function if you feel the need to):

const people = [
  { firstname: "Bill", lastname: "Harold", age: 54 },
  { firstname: "Ana", lastname: "Atkins", age: 42 },
  { firstname: "John", lastname: "Doe", age: 57 },
  { firstname: "Davy", lastname: "Johnson", age: 34 },
];

const parsePeople = (people) => {
  const parsedPeople = [];

  for (let i = 0; i < people.length; i++) {
    people[i].firstname = people[i].firstname.toUpperCase();
    people[i].lastname = people[i].lastname.toUpperCase();
  }

  const compareAges = (person1, person2) => person1.age - person2.age;

  return people.sort(compareAges);
};

parsePeople(people);
// [
//   {firstname: "DAVY", lastname: "JOHNSON", age: 34},
//   {firstname: "ANA", lastname: "ATKINS", age: 42},
//   {firstname: "BILL", lastname: "HAROLD", age: 54},
//   {firstname: "JOHN", lastname: "DOE", age: 57},
// ]

Check answers.

Immutability

Like we've seen previously, a common side-effect is to mutate a variable.

You don't want to do that in functional programming. So an important characteristic of a functional program is the immutability of data.

In functional languages like Clojure and Haskell, this feature is built-in – you have no way to mutate the data unless the language allows it. In any case, you must consciously opt to do so.

But in JavaScript, that's not the case.

So it's more about having the "immutability" mindset than a real robust implementation of this feature.

What this means is that you will basically make copies of the data you want to work on.

In the first section, we saw that JavaScript functions automatically make copies of the arguments passed. While primitive values are copied by value, compound values are only copied by reference, so it's still possible to mutate them.

Thus, when working with an object/array in a function, you should make a copy and then operate on it.

By the way, notice that some built-in functions doesn't mutate the value it's called upon, while others do.

For example, Array.prototype.map, Array.prototype.filter, or Array.prototype.reduce are don't mutate the original array.

On the other hand, Array.prototype.reverse and Array.prototype.push are mutate the original array.

You can find out if a built-in function mutates the value it's called upon or not in the documentation, so check it out if you're not sure.

That's annoying, and ultimately not perfectly safe.

Shallow vs. deep copies

Since ES6, it's easy to make object/array copies through spread notation, Array.from(), Object.assign().

For example:

// arrays
const fruits = ["apple", "strawberry", "banana"];
const fruitsCopy = [...fruits];
fruitsCopy[0] = "mutation";
// fruitsCopy: ['mutation', 'strawberry', 'banana']
// fruits (not mutated): ['apple', 'strawberry', 'banana']

// objects
const obj = { a: 1, b: 2, c: 3 };
const objCopy = { ...obj };
objCopy.a = "mutation";
// objCopy: {a: "mutation", b: 2, c: 3}
// obj (not mutated): {a: 1, b: 2, c: 3}
console.log(obj);
console.log(objCopy);

That's cool but there's a gotcha.

Spread arrays/objects only have there first level copied by value, also known as a shallow copy.

So all subsequent levels are still mutable:

// But with nested objects/arrays, that doesn't work
const nestedObj = { a: { b: "canBeMutated" } };
const nestedObjCopy = { ...nestedObj };
nestedObjCopy.a.b = "hasBeenMutated!";
console.log(nestedObj);
console.log(nestedObjCopy);
// nestedObjCopy: {a: {b: "hasBeenMutated!"}}}
// nestedObj (mutated): {a: {b: "hasBeenMutated!"}}

To resolve this problem, we need a custom function to do deep copies. This article discusses multiple solutions.

Here's a shortened version of the custom function proposed in it:

// works for arrays and objects
const deepCopy = (obj) => {
  if (typeof obj !== "object" || obj === null) {
    return obj; // Return the value if obj is not an object
  }

  // Create an array or object to hold the values
  let newObj = Array.isArray(obj) ? [] : {};

  for (let key in obj) {
    // Recursively (deep) copy for nested objects, including arrays
    newObj[key] = deepCopy(obj[key]);
  }

  return newObj;
};

const nestedObj = {
  lvl1: { lvl2: { lvl3: { lvl4: "tryToMutateMe" } } },
  b: ["tryToMutateMe"],
};
const nestedObjCopy = deepCopy(nestedObj);

nestedObjCopy.lvl1.lvl2.lvl3.lvl4 = "mutated";
nestedObjCopy.b[0] = "mutated";

console.log(nestedObj);
// { lvl1: { lvl2: { lvl3: { lvl4: "tryToMutateMe" } } }, b: ["tryToMutateMe"]}
console.log(nestedObjCopy);
// { lvl1: { lvl2: { lvl3: { lvl4: "mutated" } } }, b: ["mutated"]}

If you already use a library that provides functional utilities, it's likely that it has one to do deep copies. I personally like Ramda. See its clone function.

If the difference between shallow and deep copies still isn't clear, check this out.

Now let's talk about performance.

Obviously, making copies doesn't come without a cost.

For performance-sensitive parts of the program, or in cases where changes happen frequently, creating a new array or object (especially if it contains lots of data) is undesirable for both processing and memory reasons.

In these cases, using immutable data structures from a library like Immutable.js is probably a better idea.

They use a technique called structural sharing which I referred to when talking about the downsides of FP earlier in this post.

Check out this great talk to learn more.

Dealing with immutable data is thus, in my opinion, the second skill to have in your functional programmer tool belt.

Composition and Currying

Composition

Unsurprisingly, the fundamental building blocks of a functional program are functions.

Because your functions are free of side-effects and considered first-class, we can compose them.

Like I said, first-class means that they're treated as regular data structures, possibly being assigned to variables, passed as arguments, or returned from other functions.

Composition is a powerful idea.

From tiny little functions, you can add up their functionalities to form a more complex one, but without the pain of laying it down upfront.

In addition, you get greater flexibility because you can easily rearrange your compositions.

Being backed up by mathematical laws, we know that everything will work if we follow them.

Let's introduce some code to make things concrete:

const map = (fn, arr) => arr.map(fn);

const first = (xs) => xs[0];

const formatInitial = (x) => x.toUpperCase() + ".";

const intercalate = (sep, arr) => arr.join(sep);

const employees = ["Yann", "Brigitte", "John", "William"];

const initials = intercalate("\n", map(formatInitial, map(first, employees)));
// Y.
// B.
// J.
// W.

Ouch – there's a little bit of nesting here.

Take some time to understand what's going on. As you can see, there are function calls passed as arguments to outer functions.

With the power of map, we essentially composed the functionalities of first, formatInitial, and join to eventually apply them on the employees array.

Pretty cool!

But as you can see, nesting is annoying. It makes things harder to read.

Currying

To flatten that stuff and make composition a breeze, we have to talk about currying.

This term may scare you, but don't worry, it's just jargon for a simple idea: feeding a function one argument at a time.

Usually, when we make a function call, we provide all the arguments at once and get back the result:

const add = (x, y) => x + y;

add(3, 7);
// 10

But what if we could pass only one argument and provide the second one later?

Well, we can do that by currying add like so:

const add = (x) => (y) => x + y;

const addTo3 = add(3);
// (y) => 3 + y

// ...later
addTo3(7);
// 10

This can be useful if we don't have all the arguments yet.

You might not understand why we wouldn't have all the arguments beforehand, but you'll see later.

Thanks to closures, we're preloading the function with its arguments step-by-step until we eventually run it.

If you have a hard time grasping the concept of closure, check this, then this to go deeper.

In short, closure allows an inner function to access variables of an outer function's scope. That's why we can access x in the scope of addTo3 which comes from the outer scope, add.

Often you don't want to bother writing your functions in this special form. In addition, you can't always write them this way, for example, when you use external library functions and virtually anything you don't write but use all the same.

For this reason, there's a common helper to curry a function (from Kyle Simpson book YDKJS):

const curry = (fn, arity = fn.length) => {
  return (function nextCurried(prevArgs) {
    return function curried(...nextArgs) {
      const args = [...prevArgs, ...nextArgs];

      return args.length < arity ? nextCurried(args) : fn(...args);
    };
  })([]);
};

curry takes a function and a number called arity (optional).

The arity of a function is the number of arguments it takes.

In the case of add, it's 2.

We need that information to know when all the arguments are there, and thus decide to run the function or return another curried function that will take the remaining ones.

So let's refactor our example with add:

const add = curry((x, y) => x + y);

const addTo3 = add(3);

addTo3(7);
// 10

Or we can still call add with all its arguments directly:

const add = curry((x, y) => x + y);

add(3, 7);
// 10

Partial application

Actually, curried strictly means "takes one argument at a time", no more, no less.

When we can provide the number of arguments we want, we're actually talking about partial application.

Thus, currying is a constrained form of partial application.

Let's see a more explicit example of partial application compared to currying:

const listOf4 = curry((a, b, c, d) => `1. ${a}\n2. ${b}\n3. ${c}\n4. ${d}`);

// strict currying

const a = listOf4("First")("Second")("Third")("Fourth");
// or
const b = listOf4("First");
// later
const c = b("Second")("Third");
// later
const d = c("Fourth");

// partial application

const e = listOf4("First", "Second", "Third", "Fourth");
// or
const b = listOf4("First");
// later
const c = b("Second", "Third");
// later
const d = c("Fourth");

Do you see the difference?

With currying, you should provide one argument at a time. If you want to feed more than one argument, then you need to make a new function call, hence the pair of parentheses around each argument.

Honestly, that's just a matter of style.

It seems a bit awkward when you're not used to it, but on the other hand, some people find the partial application style to be messy.

The curry helper I introduced allows you to do both.

It stretches the real definition of currying, but I prefer to have both functionalities and don't like the name looseCurry that Kyle Simpson used in is book. So, I cheated a little bit.

Just keep the differences in mind and be aware that curry helpers you find in libraries probably follow the strict definition.

Data comes last

A final point I want to make is that we usually place the data as the last argument.

With the previous functions I used, it's not obvious because all arguments are data. But take a look at this:

const replace = curry((regex, replacement, str) =>
  str.replace(regex, replacement)
);

You can see that the data (str) is in the last position because it's likely to be the last thing we'll want to pass through.

You will see that this is the case when composing functions.

Bring it all together

Now to take advantage of currying and flatten our nested jumble from before, we also need a helper for composition.

You guessed it, it's called compose!:

const compose = (...fns) =>
  fns.reverse().reduce((fn1, fn2) => (...args) => fn2(fn1(...args)));

compose takes functions as arguments and returns another function which takes the argument(s) to pass through the whole pipeline.

Functions are applied from right to left because of fns.reverse().

Because compose returns a function that takes the future argument(s), we can freely associate our functions without calling them, which allow us to create intermediate functions.

So with our initial example:

const map = (fn, arr) => arr.map(fn);

const first = (xs) => xs[0];

const formatInitial = (x) => x.toUpperCase() + ".";

const intercalate = (sep, arr) => arr.join(sep);

const getInitials = compose(formatInitial, first);

const employees = ["Yann", "Brigitte", "John", "William"];

const initials = intercalate("\n", map(getInitials, employees));
// Y.
// B.
// J.
// W.

first and formatInitial already take one argument.

But map and intercalate take 2 arguments, so we can't include them as is in our compose helper because only one argument will be passed. In this case it's an array that both take as a final argument (remember, data is the last thing to get passed).

It would be nice to give map and intercalate their respective first argument in advance.

Wait a minute – we can curry them!:

// ...

const map = curry((fn, arr) => arr.map(fn));

const intercalate = curry((sep, arr) => arr.join(sep));

const formatInitials = compose(
  intercalate("\n"),
  map(formatInitial),
  map(first)
);

const employees = ["Yann", "Brigitte", "John", "William"];

const initials = formatInitials(employees);
// Y.
// B.
// J.
// W.

So clean!

Like I said, compose makes a pipeline with the functions we give it, calling them from right to left.

So let's visualize what happens when formatInitials(employees) is parsed:

Personally, I prefer when it goes from left to right, because when writing the function, I like to think about what transformation to apply first, write it down, then repeat until the end of the pipeline.

Whereas with compose, I have to step back to write the next transformation. That just breaks the flow of my thinking.

Fortunately, it's not complicated to tweak it in order to go from left to right.

We just have to get rid of the .reverse() part.

Let's call our new helper pipe:

const pipe = (...fns) => fns.reduce((fn1, fn2) => (...args) => f2(f1(...args)));

So if we refactor the previous snippet, we get:

const formatInitials = pipe(map(first), map(formatInitial), intercalate("\n"));

For the visualization, same thing as compose but in reverse order:

Hindley-Milner type signatures

As you know, a complete program ends up with quite a few functions.

When you plunge back into a project after several weeks, you don't have the context to easily understand what each function does.

To counter that, you reread only the parts you need. But this can be quite tedious.

It would be nice to have a quick and powerful way to document your functions and explain what they do at a glance.

That's where type signatures come in. They are a way to document how a function operates and its inputs and outputs.

For example:

// ↓ function name
//                  ↓ input
//                            ↓ output
// formatInitial :: String -> String
const formatInitial = (x) => x.toUpperCase() + ".";

Here we see that formatInitial takes a String and returns a String.

We don't care about the implementation.

Let's look at another example:

// first :: [a] -> a
const first = (xs) => xs[0];

Types can be expressed with variables (usually a, b, etc.) and the brackets means "an array of" whatever is inside.

So we could literally read this signature like this:

first takes an array of a and returns an a, where a can be of any type.

But because the type taken as input is the same as the one returned as output, we use the same variable.

If the output had another type, we would have used b:

// imaginaryFunction :: a -> b

Warning!

That doesn't ensure that a and b are different types. They still can be the same.

Finally, let's see the case of intercalate which is a bit more complex:

// intercalate :: String -> [a] -> String
const intercalate = curry((sep, arr) => arr.join(sep));

OK, here there are 2 arrows, which can be replaced by "returns...".

They indicate functions.

So intercalate takes a String then returns a function which takes an array of a, which returns a String.

Wow, that's hard to keep track of.

We could have written the signature like this:

// intercalate :: String -> ([a] -> String)

Now it's more obvious that it first returns a function, which is in parentheses here. And then that function will take [a] as input and return String.

But we usually don't use them for clarity sake. Basically, if you stumble upon a signature of the form:

// imaginaryFunction :: a -> b -> c -> d -> e

// or

// imaginaryFunction :: a -> (b -> (c -> (d -> e)))

// ...you see how parens nesting affects readability

e, the type on the right side, is the output.

And everything before are inputs given one-by-one, which indicates that the function is curried.

Nowadays, we usually have type systems like TypeScript or Flow, and the IDE is able to give us the type signature of a function when we hover over its name. Thus, it might be unnecessary to write them as comments in your code.

But this remains a nice tool to have in your toolkit because a lot of functional libraries out there use these type signatures in their documentations. And idiomatic functional languages (like Haskell) use them heavily.

So if you give them a shot, you will hopefully not be completely lost.

Pat yourself on the back for having read this far.

You should now have the ability to work with higher-order functions. Higher-order functions are simply functions that take functions as inputs and/or return them.

Indeed, that's exactly what we did.

For example, curry is an higher-order function because it takes a function as input and returns one as output.

compose, pipe, map, and reduce are all higher-order functions because they take at least one function as input.

They are pretty cool because they allow to create very powerful abstractions.

Enough nattering. Let's get some practice.

Exercises (Set 2)

1. Given a string of the form:

const input = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.";

...and these helpers:

// filter :: (a -> Boolean) -> [a] -> [a]
const filter = curry((fn, arr) => arr.filter(fn));

// removeDuplicates :: [a] -> [a]
const removeDuplicates = (arr) => Array.from(new Set(arr));

// getChars :: String -> [Character]
const getChars = (str) => str.split("");

// lowercase :: String -> String
const lowercase = (str) => str.toLowerCase();

// sort :: [a] -> [a]
const sort = (arr) => [...arr].sort();

Create a function getLetters that returns all the letters in a string without duplicates, in alphabetical order, and in lowercase.

The goal is to use compose and/or pipe:

// getLetters :: String -> [Character]
const getLetters = ...

Note: You may have to create intermediate functions before the final one.

2. Imagine you have an object with groups' names as keys and arrays of objects representing people as values:

{
  "groupName": [
    {firstname: "John", lastname: "Doe", age: 35, sex: "M"},
    {firstname: "Maria", lastname: "Talinski", age: 28, sex: "F"},
    // ...
  ],
  // ...
}

Create a function that returns an object of the form:

{
  "groupName": {
    "medianAgeM": 34,
    "medianAgeF": 38,
  },
  // ...
}

Where medianAgeM is the median age of men in the group and medianAgeF the one of women.

Here's some helpers:

// map :: (a -> b) -> [a] -> [b]
const map = curry((fn, arr) => arr.map(fn));

// getEntries :: Object -> [[Key, Val]]
const getEntries = (o) => Object.entries(o);

// fromEntries:: [[Key, Val]] -> Object
const fromEntries = (entries) => Object.fromEntries(entries);

// mean :: Number -> Number -> Number
const mean = curry((x, y) => Math.round((x + y) / 2));

// reduceOverVal :: (b -> a -> b) -> b -> [Key, [a]] -> [Key, b]
const reduceOverVal = curry((fn, initVal, entry) => [
  entry[0],
  entry[1].reduce(fn, initVal),
]);

You may have to create intermediate functions before the final one, and like before, try to use compose and pipe:

// groupsMedianAges :: Object -> Object
const groupsMedianAges = ...

3. Find the type signature of reduce:

const reduce = curry((fn, initVal, arr) => arr.reduce(fn, initVal));

4. Find the type signature of curry:

const curry = (fn, arity = fn.length) => {
  return (function nextCurried(prevArgs) {
    return function curried(...nextArgs) {
      const args = [...prevArgs, ...nextArgs];

      return args.length < arity ? nextCurried(args) : fn(...args);
    };
  })([]);
};

Check answers.

Working with boxes: From Functors to Monads

You may already be stressed out by the title of this section. You might be thinking, "What the heck are 'Functors' and 'Monads'?"

Or maybe you've heard about monads because they're famously "difficult" to understand.

Unfortunately, I can't predict that you will definitely understand these concepts, or effectively apply them in whatever work you do.

In fact, if I talk about them at the end of this tutorial, it's because I think they're very powerful tools that we don't need very often.

Here's the reassuring part: Like anything in the world, they're not magic.

They follow the same rules of physics (and more specifically computer science and math) as everything else.

So at the end of the day, they're understandable. It just requires the right amount of time and energy.

In addition, they essentially build upon what we've previously talked about: types, mapping and composition.

Now, find that tube of perseverance in your toolkit and let's get started.

Why use boxes?

We want to make our program with pure functions. Then we use composition to specify in which order to run them over the data.

However, how do we deal with null or undefined? How do we deal with exceptions?

Also, how do we manage side-effects without losing control, because one day we'll need to perform them?

The first two cases involve branching. Either the value is null and we do this, or we do that. Either there's an error and we do this, or a success and we do that.

The usual way to deal with branching is control flow.

However, control flow is imperative. It describes "how" the code operates.

So functional programmers came up with the idea of using a box that contains one of two possible values.

We use that box as input/output to functions regardless of what's inside.

But because those boxes also have specific behaviors that abstract function application, we can apply a function over a box and it will decide how to actually perform it depending on its inner value.

Thus, we don't have to adapt our functions to the data. We don't have to clutter them with logic that doesn't belong to.

Things like:

const myFunc = (x) => {
  // ...
  if (x !== null) {
    // ...
  } else {
    // ...
  }
};

With that, we can implement branching (and other stuff) while using only functions and preserve composition.

The boxes we'll see, named Algebraic Data Types (ADT), enable us to do more while keeping the data and the functions separate.

Functors and monads are indeed Algebraic Data Types.

Functors

Functors are containers/data structures/types that hold data along with a map method.

This map method allow us to apply a function on the value(s) contained in the functor. What's returned is the same functor but containing the result of the function call.

Let's introduce Identity, the simplest functor:

We could implement it with a class, but I'll use regular functions here:

const Identity = (x) => ({
  inspect: () => `Identity(${x})`,
  map: (fn) => Identity(fn(x)),
  value: x,
});

// add5 :: Number -> Number
const add5 = (x) => x + 5;

const myFirstFunctor = Identity(1);

myFirstFunctor.map(add5);
// Identity(6)

You see? Not that complicated!

Identity is the equivalent of the identity function but in the world of functors.

identity is a well-known function in FP that may seem useless at first sight:

// identity :: a -> a
const identity = (x) => x;

It does nothing on the data, just returns it as is.

But it can be useful when doing stuff like composition because sometimes, you don't want to do anything with the data, just pass it through.

And because composition works with functions and not raw values, you need to wrap them into the identity function.

Identity serves the same purpose but when composing functors.

More on that later.

Returning back to the previous snippet, we could have done map(add5, 1) and it would have given us the same result apart from the fact that there would not have been a container around it.

So there's no extra feature here.

Now let's see another functor called Maybe:

const Nothing = () => ({
  inspect: () => `Nothing()`,
  map: Nothing,
});

const Maybe = { Just, Nothing };

// Just is equivalent to Identity

Maybe is a mix of 2 functors, Just and Nothing.

Nothing contains, well, nothing. But it's still a functor so we can use it wherever we need functors.

Maybe, like its name suggests, may contain a value (Just) or not (Nothing).

Now how would we use it?

Most of the time, it's used in functions that can return null or undefined:

// isNothing :: a -> Boolean
const isNothing = (x) => x === null || x === undefined;

// safeProp :: String -> Object -> Maybe a
const safeProp = curry((prop, obj) =>
  isNothing(obj[prop]) ? Maybe.Nothing() : Maybe.Just(obj[prop])
);

const o = { a: 1 };

const a = safeProp("a", o);
// Just(1)

const b = safeProp("b", o);
// Nothing

a.map(add5);
// Just(6)

b.map(add5);
// Nothing

Do you see were the power of Maybe lies?

You can safely apply a function on the inner value within whatever functor safeProp returns, you will not get an unexpected NaN result because you added a number with null or undefined.

Thanks to the Nothing functor, the function mapped will not be called at all.

However, Maybe implementations often cheat a little bit by doing the isNothing check inside the monad, whereas a strictly pure monad shouldn't:

const Maybe = (x) => ({
  map: (fn) => (x === null || x === undefined ? Maybe(x) : Maybe(fn(x))),
  inspect: () => `Maybe(${x})`,
  value: x,
});

// safeProp :: String -> Object -> Maybe a
const safeProp = curry((prop, obj) => Maybe(obj[prop]));

const o = { a: 1 };

const c = safeProp("a", o);
// Maybe(1)

const d = safeProp("b", o);
// Maybe(undefined)

c.map(add5);
// Maybe(6)

d.map(add5);
// Maybe(undefined)

The advantage of having these functors is that, to be called "functors", they must implement a specific interface, in this case map.

Thus, each type of functor has unique features while having capabilities shared by all functors, which make them predictable.

When using Maybe in real cases, we eventually need to do something with the data to release the value.

In addition, if the operations took the unwanted branch and fails, we'll get Nothing.

Let's imagine we want to print the value retrieved from o in our previous example.

We might want to print something more useful to the user than "Nothing" if the operation failed.

So for releasing the value and provide a fallback if we get Nothing, we have a little helper called maybe:

// maybe :: c -> (a -> b) -> Maybe a -> b | c
const maybe = curry((fallbackVal, fn, maybeFunctor) =>
  maybeFunctor.val === undefined ? fallbackVal : fn(maybeFunctor.val)
);

// ...

const o = { a: 1 };

const printVal1 = pipe(
  safeProp("a"),
  maybe("Failure to retrieve the value.", add5),
  console.log
);

const printVal2 = pipe(
  safeProp("b"),
  maybe("Failure to retrieve the value.", add5),
  console.log
);

printVal1(o);
// console: 6
printVal2(o);
// console: "Failure to retrieve the value."

Great!

If this is the first time you've been exposed to this concept, that might seem unclear and unfamiliar.

But actually, it's something you're already familiar with.

If you're familiar with JavaScript, chances are that you've used the built-in map:

[1, 2, 3].map((x) => x * 2);
// [2, 4, 6]

Well, remember the definition of a functor. It's a data structure that has a map method.

Now look at the previous snippet: what's the data structure that has a map method here?

The Array! The native Array type in JavaScript is a functor!

Its specialty is that it can contain multiple values. But the essence of map stays the same: it takes a value as input and returns/maps it to an output.

So in this case, the mapper function runs for each value.

Cool!

Now that we know what's a functor, let's move on to extend its interface.

Pointed

A pointed functor is one that has an of (aka pure, unit) method.

So with Maybe that gives us:

const Maybe = {Just, Nothing, of: Just};

of is meant to place a given value into the default minimum context of the functor.

You may ask:

Why Just and not Nothing ?

When using of, we expect to be able to map right away.

If we use Nothing, it would ignore everything we map.

of expects you to insert a "successful" value.

Thus, you can still shoot yourself in the foot by inserting undefined, for example, and then map a function that doesn't expect this value:

Maybe.of(undefined).map((x) => x + 1);
// Just(NaN)

Let's introduce another functor to better understand when it's useful:

const IO = (dangerousFn) => ({
  inspect: () => `IO(?)`,
  map: (fn) => IO(() => fn(dangerousFn())),
});

IO.of = (x) => IO(() => x);

Unlike Just, IO don't get a value as is but needs it wrapped in a function.

Why is that?

I/O stands for Input/Output.

The term is used to describe any program, operation, or device that transfers data to or from a computer and to or from a peripheral device.

So it's intended to be used for input/output operations, which are side-effects because they rely on/affect the outside world.

Querying the DOM is an example:

// getEl :: String -> DOM
const getEl = (sel) => document.querySelector(sel);

This function is impure because given a same input, it can return different outputs:

getEl("#root");
// <div id="root"></div>

// or

getEl("#root");
// <div id="root">There's text now !</div>

// or

getEl("#root");
// null

Whereas by inserting an intermediate function, getEl returns always the same output:

// getEl :: String -> _ -> DOM
const getEl = (sel) => () => document.querySelector(sel);

getEl("#root");
// function...

Whatever the argument passed is, getEl will always return a function, allowing it to be pure.

However, we're not magically erasing the effect because now, it's the returned function that's impure.

We get purity out of laziness.

The outer function only serves as a protective box that we can pass around safely. When we are ready to release the effect, we call the returned function's function.

And because we want to be careful doing so, we name the function unsafePerformIO to remind the programmer that it's dangerous.

Until then, we can do our mapping and composition stuff peacefully.

So that's the mechanism used by IO.

If you pass a value directly to it, it must be a function with the same signature as the one that getEl returns:

const a = IO(() => document.querySelector("#root"));

// and not:

const invalid = IO(document.querySelector("#root"));

But as you can imagine, it quickly becomes tedious to always wrap our value in a function before passing it into IO.

Here's where of shines – it will do that for us:

const betterNow = IO.of(document.querySelector("#root"));

That's what I meant by default minimum context.

In the case of IO, it's wrapping the raw value in a function. But it can be something else, it depends of the functor in question.

Exercises (Set 3)

1. Write a function uppercaseF that uppercase a string inside a functor:

// uppercaseF :: Functor F => F String -> F String
const uppercaseF = ...

2. Use the uppercaseF function you previously built, maybe, and safeProp to create a function that retrieves the name of a user and prints an uppercased version of it.

The user object has this form:

{
  name: "Yann Salmon",
  age: 18,
  interests: ["Programming", "Sport", "Reading", "Math"],
  // ...
}

// safeProp :: String -> Object -> Maybe a

// maybe :: c -> (a -> b) -> Maybe a -> b | c

// printUsername :: User -> _
const printUsername = ...

Check answers.

Applicatives

If you work with functors, you will stumble upon situations where you have multiple functors containing values on which you would like to apply a function:

// concatStr :: String -> String -> String
const concatStr = curry((str1, str2) => str1 + str2);

const a = Identity("Hello");

const b = Identity(" world !");

Unfortunately, we can't pass functors as arguments to concatStr because it expects strings.

The Applicative interface solves that problem.

A functor that implements it is one that implements an ap method. ap takes a functor as argument and returns a functor of the same type.

Within the returned functor, there will be the result of mapping the value of the functor ap was called on, over the value of the functor previously taken as argument.

I know that's a lot to digest. Take some time and let that sink in.

Let's continue our previous snippet to see it in action:

// concatStr :: String -> String -> String
const concatStr = curry((str1, str2) => str1 + str2);

const a = Identity("Hello");

const b = Identity(" world !");

const c = a.map(concatStr);
// Identity(concatStr("Hello", _))

const result = c.ap(b);
// Identity("Hello world !")

First, we map concatStr over a. What happens is that concatStr("Hello") is called and becomes the inner value of c, still an Identity functor.

And remember, what does return concatStr("Hello")? Another function that waits for the remaining arguments!

Indeed, concatStr is curried.

Note that currying is necessary in order to use this technique.

Then, like I said, ap maps the value of the functor it's called on (in this case c, so it maps concatStr("Hello")) over the value of the functor taken as argument (here it's b containing " world !").

So result ends up being an Identity functor (same type as b) containing the result of concatStr("Hello")(" world !"), that is "Hello world !"!

Here's the implementation:

const Identity = (x) => ({
  inspect: () => `Identity(${x})`,
  // Functor interface
  map: (fn) => Identity(fn(x)),
  // Applicative interface
  ap: (functor) => functor.map(x),
  value: x,
});

// Pointed interface
Identity.of = (x) => Identity(x);

As you can see, the functor ap is called on must contain a function. Otherwise it wouldn't work. In our previous example, that was the c step.

If we inline everything, we get:

// concatStr :: String -> String -> String
const concatStr = curry((str1, str2) => str1 + str2);

const result = Identity("Hello").map(concatStr).ap(Identity(" world !"));
// Identity("Hello world !")

There's an interesting mathematical property about ap:

F(x).map(fn) === F(fn).ap(F(x));

The left side of the equality corresponds to what we did previously.

So following the right side, result could also be written like this:

const result = Identity(concatStr)
  .ap(Identity("Hello"))
  .ap(Identity(" world !"));

Take the time to reread if you feel overwhelmed.

The latter version ressembles more to a regular function call than the previous. We're feeding concatStr with its arguments in a left-to-right manner:

And all of that happens inside our protecting container.

Finally, we can further clean up this process with parametrization.

A function called liftA2 do that:

// liftA2 :: Apply functor F => (a -> b -> c) -> F a -> F b -> F c
const liftA2 = curry((fn, F1, F2) => F1.map(fn).ap(F2));

// ...

const result = liftA2(concatStr, Identity("Hello"), Identity(" world !"));

I'm sure we can agree that this name is really awkward.

I guess it made sense for the pioneers of Functional Programming, who were probably "math" people.

But anyway, you can think of it as "lifting" a function and its arguments, then putting them into a functor in order to ap each one on the other.

However, this metaphor is just partially true because arguments are already given within their container.

The interesting part is the body of the function.

You can notice that it uses the left-hand side of the mathematical property we saw earlier.

If we implement it using the right-hand side, we need to know what type of functor F1 and F2 are because we need to wrap the function with the same:

const liftA2 = curry((fn, F1, F2) => F(fn).ap(F1).ap(F2));
//                                   ↑ what's F ? We need the precise constructor.

So by using the left version, we abstract the functor type for free.

Now you might think, "OK, but what if the function requires 3, 4, or more arguments?"

If that's the case, you can build variants just by extending our previous liftA2:

// liftA3 :: Apply functor F => (a -> b -> c -> d) -> F a -> F b -> F c -> F d
const liftA3 = curry((fn, F1, F2, F3) => F1.map(fn).ap(F2).ap(F3));

// liftA4 :: Apply functor F => (a -> b -> c -> d -> e) -> F a -> F b -> F c -> F d -> F e
const liftA4 = curry((fn, F1, F2, F3, F4) => F1.map(fn).ap(F2).ap(F3).ap(F4));

// take3Args :: String -> String -> Number -> String
const take3Args = curry(
  (firstname, lastname, age) =>
    `My name is ${firstname} ${lastname} and I'm ${age}.`
);

// take4Args :: a -> b -> c -> d -> [a, b, c, d]
const take4Args = curry((a, b, c, d) => [a, b, c, d]);

liftA3(take3Args, Identity("Yann"), Identity("Salmon"), Identity(18));
// Identity("My name is Yann Salmon and I'm 18.")

liftA4(take4Args, Identity(1), Identity(2), Identity(3), Identity(4));
// Identity([1, 2, 3, 4])

As you can notice, A* refers to the number of arguments.

Wow! We've covered a bunch of things.

Again, I want to congratulate you for the time and attention you've given so far.

We almost have a fully fledged toolbox for resolving real world problems in a functional way.

We now need to explore the Monad interface.

Exercises (Set 4)

Consider this user object for the next 2 exercises:

const user = {
  id: "012345",
  name: "John Doe",
  hobbies: ["Cycling", "Drawing"],
  friends: [
    {name: "Mickael Bolp", ...},
    // ...
  ],
  partner: {name: "Theresa Doe", ...},
  // ...
}

1. Create a function that returns a phrase describing the couple if the user has a partner using the given helpers and ap:

// safeProp :: String -> Object -> Maybe a
const safeProp = curry((prop, obj) =>
  obj[prop] === undefined || obj[prop] === null
    ? Maybe.Nothing()
    : Maybe.Just(obj[prop])
);

// getCouplePresentation :: User -> User -> String
const getCouplePresentation = curry(
  (name1, name2) => `${name1} and ${name2} are partners.`
);

// getName :: User -> String
const getName = (user) => user.name;
// I could have written: const getName = safeProp("name")
// but I didn't and that's intentional.
// We assume that a user always has a name.

const couple = ...

2. Refactor the previous answer using liftA2 (check out the answer of the previous question before):

// liftA2 :: Apply functor F => (a -> b -> c) -> F a -> F b -> F c
const liftA2 = curry((fn, F1, F2) => F1.map(fn).ap(F2));

const couple = ...

Check answers.

Monads

In the exercises just before, I gave the helper getName whereas we could have derived it from safeProp.

The reason I did that is because safeProp returns a Maybe functor.

Thus, by trying to get the partner's name of a user, we end up with 2 nested Maybe functors:

const getPartnerName = pipe(safeProp("partner"), map(safeProp("name")));
// Maybe(Maybe("Theresa Doe"))

Let's see another example where this problem get even worse:

// getUser :: Object -> IO User
const getUser = ({ email, password }) => IO.of(db.getUser(email, password));

// getLastPurchases :: User -> IO [Purchase]
const getLastPurchases = (user) => IO.of(db.purchases(user));

// display :: [Purchase] -> IO _
const display = "some implementation";

// displayUserPurchases :: Object -> IO _
const displayUserPurchases = pipe(
  getUser,
  map(getLastPurchases),
  map(map(display))
);

displayUserPurchases({ email: "johndoe@whatever.com", password: "1234" });
// IO(IO(IO _))

How to get rid of these layers of container that enforce us to do nested map that impairs readability ?

Monads to our rescue! Monads are functors that can flatten.

Again, like regular functors, you will probably not use them very often.

However, they're powerful abstractions that bundle a specific set of behaviors with a value.

They're data structures backed up by mathematical laws which make them extremely predictable and reliable.

In addition, laws like composition or associativity tell us that we can do the same thing while making the operations in a different way.

Remember what we saw with Applicatives and ap:

F(x).map(fn) === F(fn).ap(F(x));

These can be helpful because certain variants might be more efficient computationaly.

The thing is that the way we prefer to write programs may differ from the way they should be written if we wanted them to be efficient as much as possible.

So because these laws ensure us that all variants do the same thing, we can write how we like and ask the compiler to use the more efficient variant later.

That's why I didn't bothered you with these laws very much. But be aware of their utility (which certainly extends beyond that).

Going back to our monads, the flattening behavior is usually implemented with a chain (aka flatMap, bind, >==) method:

const Identity = (x) => ({
  inspect: () => `Identity(${x})`,
  // Functor interface
  map: (fn) => Identity(fn(x)),
  // Applicative interface
  ap: (functor) => functor.map(x),
  // Monad interface
  chain: (fn) => fn(x),
  value: x,
});

// Pointed interface
Identity.of = (x) => Identity(x);

// chain :: Monad M => (a -> M b) -> M a -> M b
const chain = curry((fn, monad) => monad.chain(fn));

const getPartnerName = pipe(safeProp("partner"), chain(safeProp("name")));

In the case of Identity, chain is like map but without a new Identity functor surrounding it.

You may think, "That defeats the purpose, we'll get back a value unboxed!"

But, we won't because fn is meant to return a functor.

Look at the type signature of this chain helper:

// chain :: Monad M => (a -> M b) -> M a -> M b
const chain = curry((fn, monad) => monad.chain(fn));

In fact, we could do the same by first applying the function that returns a functor, which gives us a nested one, and then removing the inner or the outer.

For example:

const Identity = (x) => ({
  // ...
  chain: (fn) => Identity(x).map(fn).value,
  value: x,
});

You can see that we first wrap x, then map, then grab the inner value.

Because wrapping x in a new Identity and eventually picking its inner value are opposite, it's cleaner to do none of those like in the first version.

Now let's refactor the fist snippet of this section (with nested functors) using the chain helper:

// BEFORE
// ...

// displayUserPurchases :: Object -> IO _
const displayUserPurchases = pipe(
  getUser,
  map(getLastPurchases),
  map(map(display))
);

displayUserPurchases({ email: "johndoe@whatever.com", password: "1234" });
// IO(IO(IO _))

// AFTER
// ...

const displayUserPurchases = pipe(
  getUser,
  chain(getLastPurchases),
  chain(display)
);

displayUserPurchases({ email: "johndoe@whatever.com", password: "1234" });
// IO _

First, getUser returns an IO(User).

Then, we chain getLastPurchases instead of mapping it.

In other words, we keep the result of getLastPurchases(User) (which is IO(?)), getting rid of the original IO that surrounded User.

That's why monads are often compared to onions – flattening/chaining them is like removing an onion's layer. When you do it, you're releasing potential unwanted results which could make you cry ?.

In the last example, if the first computation getUser had returned Nothing, calling chain on it would have returned Nothing too.

This functor does no operation.

However, we need to extend the simple version we saw earlier in this post in order to give it the Applicative and Monad interfaces.

Otherwise, we couldn't use it as such:

const Nothing = () => ({
  inspect: () => `Nothing()`,
  map: Nothing,
  ap: Nothing,
  chain: Nothing,
});

Nothing.of = () => Nothing();

As long as you keep at least one layer (that is one functor) until you're ready to release the effect, that's ok.

But if you flatten the monad to get the raw value contained within all over the place because you're not able to figure out how to compose it, that defeats the purpose.

Recap

Functors apply a function to a wrapped value (map).

Pointed functors have a method to place a value in the default minimum context of the functor (of).

Applicatives apply a wrapped function to a wrapped value (ap + of).

Monads apply a function that returns a wrapped value to a wrapped value (chain + of).

Exercises (Set 5)

1. Consider this object:

const restaurant = {
  name: "The Creamery",
  address: {
    city: "Los Angeles",
    street: {
      name: "Melrose Avenue",
    },
  },
  rating: 8,
};

Create a function getStreetName that, like the name suggests, returns the street name of the restaurant.

Use safeProp (and chain, along with any other functional helpers you need) to do so in a pure way.

// safeProp :: String -> Object -> Maybe a
const safeProp = curry((prop, obj) =>
  obj[prop] === undefined || obj[prop] === null
    ? Maybe.Nothing()
    : Maybe.Just(obj[prop])
);

// getStreetName :: Object -> Maybe String
const getStreetName = ...

Check answers.

Exercise Answers

The answers I propose are not the only ones. You may come up with your own, even better solutions.

As long as your solution works, that's great.

Set 1

Go back to exercise.

1. Pure functions: a, d, e / Impure functions: b, c

For e, the answer might not be easy to understand.

It was this function:

const counter = (start, end) => {
  // ...

  // e
  () => counter(start + 1, end);
};

So it's one function inside another.

We said that a pure function shouldn't rely on the outside, but here it accesses variables outside its scope, those on which it has a closure over (counter, start and end).

In a pure functional language, unlike JavaScript, counter, start and end would be immutable so e would be pure because, for the same input (in this case none), we would always get the same output.

However, values in JavaScript are mutable by default.

So if start was an object for whatever reason, it could be mutated outside of counter or inside e itself.

In this case, e would be considered impure.

But because that's not the case here, I class it as a pure function.

See this thread for more details.

2.

const people = [
  { firstname: "Bill", lastname: "Harold", age: 54 },
  { firstname: "Ana", lastname: "Atkins", age: 42 },
  { firstname: "John", lastname: "Doe", age: 57 },
  { firstname: "Davy", lastname: "Johnson", age: 34 },
];

const uppercaseNames = (person) => ({
  firstname: person.firstname.toUpperCase(),
  lastname: person.lastname.toUpperCase(),
  age: person.age,
});

// "sort" mutates the original array it's applied on.
// So I make a copy before ([...people]) to not mutate the original argument.
const sortByAge = (people) =>
  [...people].sort((person1, person2) => person1.age - person2.age);

const parsePeople = (people) => sortByAge(people.map(uppercaseNames));

// NOT SURE TO INCLUDE
// If you have already read the section on Composition (after this one), you may come up with
// a more readable version for "parsePeople":
const parsePeople = pipe(map(uppercaseNames), sortByAge);
// or
const parsePeople = compose(sortByAge, map(uppercaseNames));

parsePeople(people);
// [
//   {firstname: "DAVY", lastname: "JOHNSON", age: 34},
//   {firstname: "ANA", lastname: "ATKINS", age: 42},
//   {firstname: "BILL", lastname: "HAROLD", age: 54},
//   {firstname: "JOHN", lastname: "DOE", age: 57},
// ]

That's the version I came with, but any variation works from the moment it has no side-effects.

The function in the exercise indeed mutates the object passed as argument.

But you can verify that the original people array is unchanged in this correction.

Set 2

Go back to exercise.

1. ```js const input = "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.";

// ...

// keepLetters :: [Character] -> [Character] | [] const keepLetters = filter((char) => "abcdefghijklmnopqrstuvwxyz".includes(char) );

// getLetters :: String -> [Character] const getLetters = pipe( lowercase, getChars, keepLetters, removeDuplicates, sort ); // or const getLetters = compose( sort, removeDuplicates, keepLetters, getChars, lowercase );

getLetters(input); // ["a", "b", "c", "d", "e", "f", "g", "h", "i", "l", "m", "n", "o", "p", "q", "r", "s", "t", "u", "v", "x"]

2.

```js
// getMedianAges :: [Key, [Person]] ->  [Key, Object]
const getMedianAges = reduceOverVal((acc, person) => {
  const key = `medianAge${person.sex}`;

  return !acc[key]
    ? { ...acc, [key]: person.age }
    : { ...acc, [key]: mean(acc[key], person.age) };
}, {});

// groupsMedianAges :: Object -> Object
const groupsMedianAges = pipe(getEntries, map(getMedianAges), fromEntries);
// or
const groupsMedianAges = compose(fromEntries, map(getMedianAges), getEntries);

3.

// reduce :: (b -> a -> b) -> b -> [a] -> b

4.

// curry :: ((a, b, ...) -> c) -> a -> b ->  ... -> c

Set 3

Go back to exercise.

1. ```js const uppercaseF = map((str) => str.toUpperCase())

// Example: const myFunctor = Just("string")

uppercaseF(myFunctor) // Just("STRING")

2.

```js
const uppercaseF = map((str) => str.toUpperCase());

// Example:
const myFunctor = Just("string");

uppercaseF(myFunctor);
// Just("STRING")

2.

// printUsername :: User -> _
const printUsername = pipe(
  safeProp("name"),
  uppercaseF,
  maybe("Username not found !", console.log)
);

// Example:
printUsername({
  name: "Yann Salmon",
  age: 18,
  interests: ["Programming", "Sport", "Reading", "Math"],
  // ...
});
// console: YANN SALMON

Set 4

Go back to exercise.

1. ```js // getPartnerName :: User -> Maybe String const getPartnerName = pipe(safeProp("partner"), map(getName));

// userName :: Maybe String const userName = Maybe.of(getName(user)); // partnerName :: Maybe String const partnerName = getPartnerName(user);

// couple :: Maybe String const couple = Maybe.of(getCouplePresentation).ap(userName).ap(partnerName); // Just("John Doe and Theresa Doe are partners.")

2.

```js
// ...

const couple = liftA2(getCouplePresentation, userName, partnerName);

Set 5

Go back to exercise.

1. ```js // ...

// getStreetName :: Object -> Maybe String const getStreetName = pipe( safeProp("address"), chain(safeProp("street")), chain(safeProp("name")) );

getStreetName(restaurant); // Just("Melrose Avenue") ```

Going further

This post is mainly inspired by what I learned from these 3 amazing resources (in order of difficulty):

• Fun Fun Function playlist (video)
• Functional-Light JavaScript (book)
• Mostly adequate guide for Functional Programming (book)

Like me, you'll certainly find some concepts really hard to grasp at first.

But please keep going. Don't hesitate to rewind videos and reread paragraphs after a good night of sleep.

I ensure you that it will pay off.

There's also a great Github repository that gather resources about Functional Programming in JavaScript.

You'll find, among other things, nice libraries that provide functional helpers. My favorite at the time is Ramda JS. Others also provide monads like Sanctuary.

I certainly don't know everything about Functional Programming, so there are topics I didn't cover.

Those I'm aware of are:

• A technique called transducing. In short, it's a way of composing map, filter and reduce operations together. Check this and that to learn more.
• Other common types of monads: Either, Map, List
• Other algebraic structures like semi-groups and monoids
• Functional Reactive Programming

Conclusion

That's it!

Before we finish, I want to warn you about potential mistakes.

I'm not an expert in Functional Programming, so please be critical of this article as you learn more about it. I'm always open to discussions and refinements.

In any case, I hope that I laid down what I consider to be the fundamentals necessary for you to be more productive in your day-to-day work, as well as giving you the tools and the interest to go further.

And with that, keep coding! ?

One day I came across this tweet from Lari Mazza:

As a software engineer who learned Python, Ruby, JavaScript, and Clojure first, when I tried C++ it was a horror movie. I couldn't do much, and it was so counterproductive and frustrating. Maybe because I was doing everything wrong and I didn't understand types the right way.

But even though I had so many problems, I could implement a bunch of algorithms and data structures.

Now that I'm using more and more TypeScript in my day-to-day job and my side projects, I feel I'm more prepared to confront types. Actually, not confront, but use them in my favor.

This post is my attempt to help developers think more in types and understand this mental model.

Thinking in JavaScript types

If you're here, you've probably heard that TypeScript is a superset of JavaScript. If not, great, you just learned something new today. YAY!

TypeScript is a superset because any JavaScript code is valid in TypeScript, syntactically speaking. It may or may not compile depending on the TypeScript compiler configuration. But in terms of syntax, it works just fine.

This is why you can migrate JavaScript to TypeScript progressively by just replacing the .js extension with the .ts. Everything will be without type declarations (the any type), but that's another story.

Also, if you code in JavaScript - or any other programming language - you probably think in types:

• "Hm, it is a list of integers, so I'll need to filter only the even numbers and return a new list"
• "This is an object, but I just need to get this string value from the property X"
• "This function receives two parameters. Both A and B are integers and I want to sum them"

Yeah, you get the idea. We think in types. But they are just in our heads. We constantly think about them because we need to know how to handle, parse, or modify data. We need to know which methods we are allowed to use in this object type.

To give a more concrete example, imagine you want to sum the price of all products. A product object looks like this:

const product = {
  title: 'Some product',
  price: 100.00,
};

But now with a list of products:

const products = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Ok! Now we want a function to sum all the products prices.

function sumAllPrices(products) {
  return products.reduce((sum, product) => sum + product.price, 0);
};

sumAllPrices(products); // 425

Just receive the products as the argument and reduce all product prices. JavaScript works just fine. But while building this function you start to think about the data and how to handle it properly.

The first part: products as an argument. Here you just think: "well, we're receiving a list of some objects". Yeah, in our heads the products are a list. This is why we can think of using the reduce method. It is a method from the Array prototype.

Then we can think about the object in detail. We know that the product object has a price property. And this property is a number. This is why we can do product.price and sum with the accumulator.

Recapping:

• products is a list of objects.
• As a list, we can use the reduce method, as this method is a member of the Array prototype.
• The produce object has some properties. One of them is the price, which is a number.
• As a number property, we can use it to sum with the reduce accumulator.
• We wanted to return a number, the sum of all products prices.

We are always thinking of data types, we just need to add the type annotations to make it more explicit and ask the compiler for help. Our memory is limited and the compilers are here to help us, humans.

The type system will not only make our data more consistent, but it can also provide autocompletion for data types. It knows the types, so it can show the members for the data. We will take a look at this idea later. Here I just wanted to show that we think in types in our heads.

Simples Types & Simple Uses

So we are ready to use some strongly typed programming languages like TypeScript. We simply need to explicitly add type annotations to our data structures. It's simple, right?

But sometimes it's not that easy (usually it's not easy when you come from dynamically typed languages. You feel unproductive. It feels like a battle against types). The idea here is to make this learning curve smoother and more fun.

Here we will see many examples of how to use types in TypeScript. We'll start with easy and silly examples and progressively make it more complex while designing the mental model to think in types.

As in JavaScript, TypeScript also has basic data types like number, string, boolean, null, etc. You can find all the basic data types in the TypeScript Docs.

With these units of data, we can make our programs more useful. To be more practical, let's get a simple example. A sum function.

How does it work in JavaScript?

function sum(a, b) {
  return a + b;
}

Everything ok? Good.

Now let's use it:

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // '0string'   WTF!

The first two calls are what we expect to happen in our system. But JavaScript is very flexible, it lets us provide any value to this function.

The last call is bizarre. We can call with a string, but it will return an unexpected result. It doesn't break in development, but it will result in strange behavior in runtime.

What do we want? We want to add some constraints to the function. It will only be able to receive numbers. That way, we narrow the possibility of having unexpected behaviors. And the function return type is also a number.

function sum(a: number, b: number): number {
  return a + b;
}

Great! It was very simple. Let's call again.

sum(1, 2); // 3
sum(2, 2); // 4
sum(0, 'string'); // Argument of type '"string"' is not assignable to parameter of type 'number'.

As we type annotate our function, we provide information to the compiler to see if everything is correct. It will follow the constraints we added to the function.

So the first two calls are the same as in JavaScript. It will return the correct calculation. But in the last one we have an error in compile time. This is important. The error now happens in compile time and prevents us from shipping incorrect code to production. It says that the string type is not part of the set of values in the number type universe.

For basic types, we just need to add a colon followed by the type definition.

const isTypescript: boolean = true;
const age: number = 24;
const username: string = 'tk';

Now let's increase the challenge. Remember the product object code we wrote in JavaScript? Let's implement it again, but now with the TypeScript mindset.

Just to remember what we are talking about:

const product = {
  title: 'Some product',
  price: 100.00,
};

This is the product value. It has a title as string and the price as number. For now, this is what we need to know.

The object type would be something like this:

{ title: string, price: number }

And we use this type to annotate our function:

const product: { title: string, price: number } = {
  title: 'Some product',
  price: 100.00,
};

With this type, the compiler will know how to handle inconsistent data:

const wrongProduct: { title: string, price: number } = {
  title: 100.00, // Type 'number' is not assignable to type 'string'.
  price: 'Some product', // Type 'string' is not assignable to type 'number'.
};

Here it breaks down into two different properties:

• The title is a string and should not receive a number.
• The price is a number and should not receive a string.

The compiler helps us to catch type errors like that.

We could improve this type annotation by using a concept called Type Aliases. It's a way to create a new name for a specific type.

In our case, the product type could be:

type Product = {
  title: string;
  price: number;
};

const product: Product = {
  title: 'Some product',
  price: 100.00,
};

It's better to visualize the type, add semantics, and maybe reuse in our system.

Now that we have this product type, we can use it to type the products list. The syntax looks like this: MyType[]. In our case, Product[].

const products: Product[] = [
  {
    title: 'Product 1',
    price: 100.00,
  },
  {
    title: 'Product 2',
    price: 25.00,
  },
  {
    title: 'Product 3',
    price: 300.00,
  }
];

Now the function sumAllPrices. It will receive the product and return a number, the sum of all product prices.

function sumAllPrices(products: Product[]): number {
  return products.reduce((sum, product) => sum + product.price, 0);
};

This is very interesting. As we typed the product, when we write product., it will show the possible properties we can use. In the product type case, it will show the properties price and title.

sumAllPrices(products); // 425
sumAllPrices([]); // 0
sumAllPrices([{ title: 'Test', willFail: true }]); // Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Passing the products will result in the value 425. An empty list will result in the value 0. And if we pass an object with a different structure - TypeScript has a structural type system and we will dig deep into this topic later - the compiler will throw a type error telling that the structure is not part of the Product type.

Structural Typing

Structural typing is a type of type compatibility. It's a way to understand the compatibility between types based on its structure: features, members, properties. Some languages have type compatibility based on the names of the types, and it's called nominal typing.

For example, in Java, even if different types have the same structure, it will throw a compile error because we are using a different type to instantiate and define a new instance.

class Person {
  String name;
}

class Client {
  String name;
}

Client c = new Person();  // compiler throws an error
Client c = new Client();  // OK!

In nominal type systems, the relevant part of a type is the name, not the structure.

TypeScript, on another hand, verifies the structural compatibility to allow or not specific data. Its type system is based on structural typing.

The same code implementation that crashes in Java, would work in TypeScript.

class Person {
  name: string;
}

class Client {
  name: string;
}

const c1: Client = new Person(); // OK!
const c2: Client = new Client(); // OK!

We want to use the Client type, and it has the property name, to point to the Person type. It also has the property type. So TypeScript will understand that both types have the same shape.

But it is not only about classes, but it works for any other "object".

const c3: Client = {
  name: 'TK'
};

This code compiles too because we have the same structure here. The TypeScript type system doesn't care about if it is a class, or an object literal if it has the same members, it will be flexible and compile.

But now we will add a third type: the Customer.

class Customer {
  name: string;
  age: number;
};

It not only has the name property, but also the age. What would happen if we instantiate a Client instance in a constant of type Customer?

const c4: Customer = new Client();

The compiler will not accept that. We want to use the Customer, that has name and age. But we are instantiating the Client that has only the name property. So it doesn't have the same shape. It will cause an error:

Property 'age' is missing in type 'Client' but required in type 'Customer'.

The other way around would work because we want Client, and Customer has all the properties (name) from Client.

const c5: Client = new Customer();

It works fine!

We can go on for enums, object literals, and any other type, but the idea here is to understand that the structure of the type is the relevant part.

Runtime and Compile time

This is a much more complex topic in programming language theory, but I wanted to give some examples to distinguish runtime from compile time.

Basically, the runtime is the execution time of a program. Imagine your backend receiving data from a frontend form page, handling this data, and saving it. Or when your frontend is requesting data from a server to render a list of Pokemons products.

Compile time is basically when the compiler is executing operations in the source code to satisfy the programming language's requirements. It can include type checking as an operation, for example.

Compile time errors in TypeScript, for example, are very related to the code that we wrote before:

• When the type is missing property: Property 'age' is missing in type 'Client' but required in type 'Customer'.
• When the type doesn't match: Type '{ title: string; willFail: true; }' is not assignable to type 'Product'.

Let's see some examples to have a better understanding.

I want to write a function to get the index of a part of the passed programming language.

function getIndexOf(language, part) {
  return language.indexOf(part);
}

It receives the language and the part that we will look for to get the index.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Uncaught TypeError: language.indexOf is not a function at getIndexOf

When passing a string, it works fine. But passing a number, we got a runtime error Uncaught TypeError. Because a number doesn't have an indexOf function, so we can't really use it.

But if we give type information to the compiler, in compile time, it will throw an error before running the code.

function getIndexOf(language: string, part: string): number {
  return language.indexOf(part);
}

Now our program knows that it will need to receive two strings and return a number. The compiler can use this information to throw errors when we get a type error... before runtime.

getIndexOf('Typescript', 'script'); // 4
getIndexOf(42, 'script'); // Argument of type '42' is not assignable to parameter of type 'string'.

Maybe, for small projects (or small functions like ours) we don't really see too much benefit.

In this case, we know that we need to pass a string, so we won't pass a number to the function. But when the codebase grows or you have many people adding code and more complexity, it's clear to me that a type system can help us a lot to get errors in compile time before shipping code to production.

At first, we need all the learning curve to understand types and all the mental models, but after a while, you'll be more used to type annotations and eventually become friends with the compiler. It would be a helper, not a yeller.

As we are learning about the basic difference between compile time and runtime, I think it's great to differentiate types from values.

All the examples I'll show here can be copied and run in the TypeScript Playground to understand the compiler and the result of the compilation process (aka the "JavaScript").

In TypeScript, we have two different universes: the value and the type spaces. The type space is where types are defined and used to enable the compiler to do all the great magic. And the value space is the values in our programs like variables, constants, functions, value literals, and things that we have in runtime.

It's good to have an understanding of this concept because in TypeScript we can't use type checking in runtime. It has a very clear separation between type checking and the compilation process.

TypeScript has the process of type checking the source code types and sees if everything is correct and consistent. And then it can compile to JavaScript.

As these two parts are separate, we can't use type checking in runtime. Only in "compile time". If you try to use a type as a value, it will throw an error: only refers to a type, but is being used as a value here.

Let's see examples of this idea.

Imagine we want to write a function called purchase where we receive a payment method and based on this method, we want to do some action. We have a credit card and a debit card. Let's define them here:

type CreditCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type DebitCard = {
  number: number;
  cardholder: string;
  expirationDate: Date;
  secutiryCode: number;
};

type PaymentMethod = CreditCard | DebitCard;

These types are in the Type space, so it only works in compile time. After type checking this function, the compiler removes all the types.

If you add these types in the TypeScript Playground, the output will be only a strict definition "use strict";.

The idea here is to really understand that the types live in the Type space and will not be available in the runtime. So in our function, it won't be possible to do this:

const purchase = (paymentMethod: PaymentMethod) => {
  if (paymentMethod instanceof CreditCard) {
    // purchase with credit card
  } else {
    // purchase with debit card
  }
}

In the compiler it throws an error: 'CreditCard' only refers to a type, but is being used as a value here..

The compiler knows the difference between the two spaces and that the type CreditCard lives in the Type space.

The playground is a very cool tool to see the output of your TypeScript code. If you create a new credit card object like this:

const creditCard: CreditCard = {
  number: 2093,
  cardholder: 'TK',
  expirationDate: new Date(),
  secutiryCode: 101
};

The compiler will type check it and do all the magic and then it transpiles the TypeScript code to JavaScript. And we have this:

const creditCard = {
    number: 2093,
    cardholder: 'TK',
    expirationDate: new Date(,
    secutiryCode: 101
};

The same object, but now only with the value and without the type.

Constraints & Type Narrowing

When we restrict what we can do, it’s easier to understand what we can do.

We use types as constraints to limit the bugs in your program. To understand this concept, I'm stealing an example from Lauren Tan's talk about Type Systems.

const half = x => x / 2;

How many ways does this function can fail? Imagine a number of possible inputs:

[
  null,
  undefined,
  0,
  '0',
  'TK',
  { username: 'tk' },
  [42, 3.14],
  (a, b) => a + b,
]

And what are the results for input:

half(null); // 0
half(undefined); // NaN
half(0); // 0
half('0'); // 0
half('TK'); // NaN
half({ username: 'tk' }); // NaN
half([42, 3.14]); // NaN
half((a, b) => a + b); // NaN

We have different and unexpected results here. Here it's clear that we want a number as the half function, do the calculation, and great, it's done! But sometimes we don't control the input or the codebase is big, or new/unfamiliar, and we're able to make these little mistakes.

The idea of adding constraints to our code is to narrow the possibilities of a range of types. In this case, we want to limit the input type to a number type. It's the only type that we care about to do the half calculation. With type narrowing, we again give type information to the compiler.

const half = (x: number) => x / 2;

And with this new information, if we call the function with the test cases again, we have different results:

half(null); // Argument of type 'null' is not assignable to parameter of type 'number'.
half(undefined); // Argument of type 'undefined' is not assignable to parameter of type 'number'.(
half(0); // 0
half('0'); // Argument of type '"0"' is not assignable to parameter of type 'number'.
half('TK'); // Argument of type '"TK"' is not assignable to parameter of type 'number'.
half({ username: 'tk' }); // Argument of type '{ username: string; }' is not assignable to parameter of type 'number'.
half([42, 3.14]); // Argument of type 'number[]' is not assignable to parameter of type 'number'.
half((a, b) => a + b); // Argument of type '(a: any, b: any) => any' is not assignable to parameter of type 'number'.

Basically the compiler will tell us that only the number type, in this case, the 0 value, is a valid input, it will compile, and allow to run the code. We narrow the input type and allow only the value we really want for this function.

But are other ways to narrow the types in TypeScript. Imagine we have a function that receives a parameter that can be either a string or a number.

type StringOrNumber = string | number;

function stringOrNumber(value: StringOrNumber) {}

In the function body, the compiler won't know which methods or properties we can use for this type. Is it a string or number? We only know about the value in runtime. But we can narrow the type using the typeof:

function stringOrNumber(value: StringOrNumber) {
  if (typeof value === 'string') {
    // value.
        // your ide will show you the possible methods from the string type
        // (parameter) value: string
    value
  }

  if (typeof value === 'number') {
    // value.
        // your ide will show you the possible methods from the number type
        // (parameter) value: number
    value
  }
}

With an if statement and the typeof, we can give more information to the compiler. Now it will know the specific type for each if body.

The IDE knows what to show for the specific type. In runtime, when the value is a string, it will go to the first if statement, and the compiler will infer that the type is a string: (parameter) value: string.

When the value is a number, it will go to the second if statement and the compiler will infer that a type is a number: (parameter) value: number.

The if statement can be a helper to the compiler.

Another example is when we have an optional property in an object, but in a function, we need to return a value based on this optional value.

Imagine we have this type:

type User = {
  name: string;
  address: {
    street: string;
    complement?: string;
  }
};

It's a simple User type. Let's focus on the complement property. It's optional (take a closer look at the ? symbol), which means that it can be a string or undefined.

Now we want to build a function to receive the user and get the length of the address complement. What about this?

function getComplementLength(user: User): number {
  return user.address.complement.length;
    // (property) complement?: string | undefined
  // Object is possibly 'undefined'.
}

As we see earlier, the complement can be a string or undefined. undefined doesn't really have a property called length:

Uncaught TypeError: Cannot read property 'length' of undefined

We could make something like:

function getComplementLength(user: User) {
  return user.address.complement?.length;
}

If the complement has a string value, we can call length, otherwise, it will return undefined.

So this function has two possible return types: number | undefined. But we want to ensure that we only return number. So we use a if or a ternary condition to narrow the type. It will only call .length when it has real value (or when it is not undefined).

function getComplementLength(user: User): number {
  return user.address.complement
    ? user.address.complement.length
    : 0;
}

If it is undefined, we return the minimum length: 0. Now we can use the function with the right type design with and without the complement. Without compile and runtime errors.

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue'
  }
}); // 0

getComplementLength({
  name: 'TK',
  address: {
    street: 'Shinjuku Avenue',
    complement: 'A complement'
  }
}); // 12

We'll get 0 from the first function call and 12 from the second call.

With this if concept, we can also use other helpers to do the same thing. We could use the in operator to verify a property from an object, a Array.isArray to verify an array, or the instanceof for any other class type.

We could also use more advanced concepts like assertion function or type guards, but I'll leave these concepts to future posts.

One thing that I want to dig deep in this Constraints topic is immutability.

In JavaScript and TypeScript, we have the idea of mutable objects. If you define value in a variable, we can reassign it with another value later.

let email = 'harry.potter@mail.com';
email // 'harry.potter@mail.com'
email = 'hermione.granger@mail.com';
email // 'hermione.granger@mail.com'

Now imagine you have a list of numbers. And you want to use a function to sum all of its numbers. The function looks like this:

function sumNumbers(numbers: number[]) {
  let sum = 0;
  let num = numbers.pop();

  while (num !== undefined) {
    sum += num;
    num = numbers.pop();
  }

  return sum;
}

You call the function passing your list and get the result. It works just fine.

const list = [1, 2, 3, 4];
sumNumbers(list); // 10

But what happened to your list? Did the function mutate it entirely?

list; // []

If we use the list, it's empty now. The pop in the sumNumbers function is a "mutate" function. It gets the references and removes the item from them. It's not a copy, it's the real reference.

In runtime, we can use other functions or ways to do the same thing: using reduce, do a for loop without the need to pop items from the array.

But using TypeScript, we can provide immutability in compile time. If you are not using types, it's possible to use a type assertion as const. Imagine this:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});

Just an author object and then we add a new book to this author. The push method updates the book's array reference. It's a "mutate" method. Let's see if you use the const assertion as const:

const author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
} as const;

author.books.push({
  title: 'Steve Jobs',
  price: 10.00
});
// Property 'push' does not exist on type
// 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'

The compiler won't compile. It gets an error on the author's object. It's is now readonly, and as a readonly object, it has no method called push (or any "mutate" method).

We added a constraint to the author's object. Before it was a specific type (with all the "mutate" methods), and now we narrowed the type to be almost the same, but without the "mutate" methods. Type narrowing.

To continue, let's add types to this object. The book and the author:

type Book = {
  title: string;
  price: number;
};

type Author = {
  name: string;
  email: string;
  books: Book[];
};

Add the type to the author object:

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

Add the type to a new book object:

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

And now we can add the new book to the author:

author.name = 'TK';
author.books.push(book);

It works just fine!

I want to show another way to add immutability in compile time. TypeScript has a utility type called Readonly.

You can add the readonly for each property in an object. Something like this:

type Book = {
  readonly title: string;
  readonly price: number;
};

But it can be very repetitive. So we can use the Readonly utility to add the readonly to all properties of an object:

type Book = Readonly<{
  title: string;
  price: number;
}>;

One thing to keep in mind is that it doesn't add the readonly for nested properties. For example, if we add the Readonly to the Author type, it won't add the readonly to the Book type too.

type Author = Readonly<{
  name: string;
  email: string;
  books: Book[];
}>;

All the properties from the author can't be reassigned, but you can mutate the books list here (push, pop, ...) because the Book[] is not readonly. Let's see it.

const author: Author = {
  name: 'Walter Isaacson',
  email: 'walter.isaacson@mail.com',
  books: [
    {
      title: 'Leonardo Da Vinci',
      price: 50.00,
    }
  ]
};

const book: Book = {
  title: 'Steve Jobs',
  price: 30
};

author.books.push(book);
author.books;
/* =>
 *
 * [
 *   {
 *     title: 'Leonardo Da Vinci',
 *     price: 50.00,
 *   },
 *   {
 *    title: 'Steve Jobs',
 *    price: 30
 *   }
 * ]
 *
 */

The push will work just fine.

So, how do we enforce a readonly to the books? We need to make sure that the array is a readonly type. We can use the Readonly, or use another utility from TypeScript called ReadonlyArray. Let's see the two ways to do it.

With Readonly:

type Author = Readonly<{
  name: string;
  email: string;
  books: Readonly<Book[]>;
}>;

With ReadonlyArray:

type Author = Readonly<{
  name: string;
  email: string;
  books: ReadonlyArray<Book>;
}>;

For me, both work great! But in my opinion, ReadonlyArray is more semantic and I also feel it is less verbose (not that the Readonly with an array is).

What happened if we try to mutate the author object now?

author.name = 'TK'; // Cannot assign to 'name' because it is a read-only property.
author.books.push(book); // Property 'push' does not exist on type 'readonly [{ readonly title: "Leonardo Da Vinci"; readonly price: 50; }]'.

Great! Now we can catch mutable operations in compile time. This is a way to use the concept of adding constraints to our types to make sure they only do what is really needed.

Semantics & Readability

At first, I felt that TypeScript could be very verbose because of the types and make the code much more complex than it should be. And it actually can. Strive for simplicity is the goal and it is difficult at the same time.

This idea is very related to clean code and how we can write code to be human-readable and maintainable. TypeScript is no different. Most of the cases, we don't need super complex types. Let the simple types do the work.

Another thing that I find very useful is semantic of types.

Imagine you need to add a string to the sessionStorage to save it in the browser. Your function looks like this:

function saveMyString(value: string): any {
  sessionStorage.myString = value;
}

You add a type annotation to the string input and as you don't know about the returning type, you probably add a any type.

But what's the real meaning behind this returning type? Is it returning anything?

It just saves the string to the sessionStorage. It doesn't return anything. The void type was what you're looking for. As TypeScript docs says: the absence of having any type at all.

function saveMyString(value: string): void {
  sessionStorage.myString = value;
}

Great, the meaning of the type is correct now. The correctness is very important in a type system. It's a way to model our data, but also help maintain systems for future developers. Even if the developer is ... you!

Before we were talking about verbose code. And we can improve a lot of our code by using TypeScript type inference.

For some code, we don't need to explicitly add type annotation. The TypeScript compiler will understand and infer it implicitly. For example:

const num: number = 1;

This code is redundant. We can just let the compiler infers it like this:

const num = 1;

In our example earlier, we add the annotation void to the saveMyString function. But as the function doesn't return any value, the compiler will infer that the returning type is void implicitly.

When I learned this, I thought with myself. But one of the biggest advantages of using TypeScript (or any other type system / static type language) is types as documentation. If we let the compiler infer most of the types, we won't have the documentation we want.

But if you hover over the TypeScript code in your editor (at least VS Code works like that), you can see the type information and relevant documentation.

Let's see other examples of redundant code and make the code less verbose and let the compiler works for us.

function sum(a: number, b: number): number {
  return a + b;
};

We don't need the returning type number, because the compiler knows that a number + another number is equal to a number type, and it is the returning type. It can be:

function sum(a: number, b: number) {
  return a + b;
};

Implicit code, but with documentation, and the compiler does the work.

Type inference works for methods too:

function squareAll(numbers: number[]): number[] {
  return numbers.map(number => number * number);
};

This function gets a list of numbers and makes every number a squared value. The returning type is number[], even though the result of a map is always a list, and as we have a list of numbers, it will always be a list of numbers. So we let the compiler infers this too:

function squareAll(numbers: number[]) {
  return numbers.map(number => number * number);
};

This works the same way for objects too.

const person: { name: string, age: number } = {
  name: 'TK',
  age: 24
};

A person object with a string name and a number age. But as we are assigning these values, the compiler can infer these types.

const person = {
  name: 'TK',
  age: 24
};

If you hover the person, you get this:

const person: {
  name: string;
  age: number;
}

The types are documented here.

Another benefit of type inference is that we can easily refactor our code. It's a simple example, but good to illustrate the refactoring process. Let's get the sum function again.

function sum(a: number, b: number): number {
  return a + b;
};

Instead of returning the sum number, we want to return "Sum: {a + b}". So for a = 1 and b = 2, we have the resulting string as "Sum: 3".

function sum(a: number, b: number): string {
  return `Sum: ${a + b}`;
};

sum(1, 2); // Sum: 3

Great! But now letting the compiler infers this.

// function sum(a: number, b: number): number
function sum(a: number, b: number) {
  return a + b;
};

// function sum(a: number, b: number): string
function sum(a: number, b: number) {
  return `Sum: ${a + b}`;
};

We just need to modify the returning value and the type inference will work. No need to think about the returning type. This is a small example, but for more complex functions, it would work too.

Back to the readability part, we can use Enum. A utility that defines a set of named constants. It's a way to give more meaning to the data in your application.

In your node app or a frontend app, you possibly do some fetching to request data. You commonly use a fetch object to perform a request and sometimes you need to pass the accept headers.

fetch('/pokemons', {
  headers: {
    Accept: 'application/json'
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: 'application/json'
  }
});

It's good, but we can also use an enum to separate this accept string in a constant and reuse.

enum MediaTypes {
  JSON = 'application/json'
}

fetch('/pokemons', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

fetch('/harry-potter/spells', {
  headers: {
    Accept: MediaTypes.JSON
  }
});

And we are able to add more data related to the MediaTypes like PDF:

enum MediaTypes {
  JSON = 'application/json',
  PDF = 'application/pdf'
}

With Enum, we can encapsulate data into a meaningful block of code.

Recently, I was implementing a "state" React component. It's basically a component that renders an empty state or an error state based on the request response.

The UI for the empty and the error states were very similar. Only the title and the description text and the image icon were different. So I thought: "I have two ways in my mind to implement this: do the logic outside the component and pass all the information needed or pass a 'state type' and let the component render the correct icon and messages."

So I built an enum:

export enum StateTypes {
  Empty = 'Empty',
  Error = 'Error'
};

And I could just pass this data to the component as the type:

import ComponentState, { StateTypes } from './ComponentState';

<ComponentState type={StateTypes.Empty} />
<ComponentState type={StateTypes.Error} />

In the component, it had a state object with all the information related to the title, description, and icon.

const stateInfo = {
  Empty: {
    title: messages.emptyTitle,
    description: messages.emptyDescription,
    icon: EmptyIcon,
  },
  Error: {
    title: messages.errorTitle,
    description: messages.errorDescription,
    icon: ErrorIcon,
  },
};

So I could just receive the type based on the enum and use this stateInfo object with the State component from our design system:

export const ComponentState = ({ type }) => (
  <State
    title={stateInfo[type].title}
    subtitle={stateInfo[type].subtitle}
    icon={stateInfo[type].icon}
  />
);

This is a way to use an enum to encapsulate important data into a meaningful block of code in your application.

Another cool feature from TypeScript is optional properties. When we have properties from an object that can be a real value or undefined, we use an optional property to be explicitly that the property can be or not be there. The syntax for this is a simple ? operator in the object property. Imagine this function:

function sumAll(a: number, b: number, c: number) {
  return a + b + c;
}

But now the c value is optional:

function sumAll(a: number, b: number, c?: number) {
  return a + b + c;
}

We add the ? after c. But now we have a compiler error saying:

(parameter) c: number | undefined
Object is possibly 'undefined'.

We can't sum an undefined value (well, actually in JavaScript we can, but we receive a NaN value).

We need to ensure that the c exists. Type narrowing!

function sumAll(a: number, b: number, c?: number) {
  if (c) {
    return a + b + c;
  }

  return a + b;
}

If the c exists, it will be a number and we can sum all. If not, sum only the a and b values.

An interesting part of this optional property is that it is a undefined not null. This is why we do this, we get a compile error:

let number = null;
sumAll(1, 2, number);
// Argument of type 'null' is not assignable to parameter of type 'number | undefined'.

As the ? operator doesn't handle the null value, choose to use the undefined type in your application and so you can still use the optional property and make the types consistent. We can use it like this:

let value: number | undefined;
sumAll(1, 2, value); // 3

If you add a default value to the parameter, you won't need the ? operator. Actually, the compiler will say that the Parameter cannot have question mark and initializer.

function sumAll(a: number, b: number, c: number = 3) {
  return a + b + c;
}

Optional properties not only works on variables and parameters, but also in objects.

An API response is a good example of type definition and optional property together. In API responses, data can be optional. Sometimes the API sends, sometimes it has no value.

How we model our types is really important for an application. If an optional property is defined as a required type, we can make our application breaks in runtime. But if we design the types correctly, we have the possible errors in compile time.

Imagine we are fetching a user data and this is the way we modeled the response type:

type UserResponse = {
  name: string;
  email: string;
  username: string;
  age: number;
  isActive: boolean;
};

But in reality, the email is optional for the user. The API endpoint could return or not. But the UserResponse type we built treat it as a required property.

After fetching the user data, we want to see if the user email matches with a specific domain.

function matchDomain(email: string) {
  return email.endsWith(domain);
}

As the email property is required in the UserResponse type, the email parameter will also be required in the matchDomain function.

This is the runtime we can get if the email is undefined:

// Uncaught TypeError: Cannot read property 'endsWith' of undefined

But what would happen if we modeled the UserResponse correctly?

type UserResponse = {
  name: string;
  email?: string;
  username: string;
  age: number;
  isActive: boolean;
};

Now the email is possibly undefined and it is explicit.

But if we still keep the function matchDomain the same way, we get a compile error:

// Argument of type 'undefined' is not assignable to parameter of type 'string'.

And this is great! Now we can fix the email parameter in this function using the ? operator:

function matchDomain(email?: string) {
  return email.endsWith('email.com');
}

But now we get a compile error when running email.endsWith, because it could be undefined too:

// (parameter) email: string | undefined
// Object is possibly 'undefined'.

Type narrowing! We use an if block to return a false when the email is undefined. And run endsWith method only if the email is really a string:

function matchDomain(email?: string) {
  if (!email) return false;
  return email.endsWith('email.com');
}

It's pretty nice when we can get runtime errors in compile time. Better to code than debugging after we ship in production, isn't it?

Type composition

Type composition is very useful when trying to reuse existing types for new places of the codebase. We don't need to rewrite new types, we can create a new type by composing existing ones.

One example of composition I always have to handle using Redux or the useReducer hook from React is the idea of "reducers". A reducer can always receive a number of different actions.

In this context, actions are objects with at least a type property. It looks like this:

enum ActionTypes {
  FETCH = 'FETCH'
}

type FetchAction = {
  type: typeof ActionTypes.FETCH;
};

const fetchAction: FetchAction = {
  type: ActionTypes.FETCH
};

A fetchAction has a type FetchAction that has a property type that is a typeof FETCH.

But a reducer can receive other actions too. For example a submit action:

enum ActionTypes {
  FETCH = 'FETCH',
  SUBMIT = 'SUBMIT'
}

type SubmitAction = {
  type: typeof ActionTypes.SUBMIT;
};

const submitAction: SubmitAction = {
  type: ActionTypes.SUBMIT
};

For a specific container, we can compose all these actions into just one type and use it for the reducer parameter type.

It would look like this:

type Actions = FetchAction | SubmitAction;

function reducer(state, action: Actions) {
  switch (action.type) {
    case ActionTypes.FETCH:
    // fetching action
    case ActionTypes.SUBMIT:
    // submiting action
  }
}

All the possible actions are the Actions type. And we use a union type to "join" all action types. The action in the reducer can have the FetchAction or the SubmitAction.

As a Potterhead, I couldn't miss a Harry Potter example. I want to build a simple function to choose a Hogwarts House based on the person trait. Let's start with the houses first.

type House = {
  name: string;
  traits: string[];
}

const gryffindor: House = {
  name: 'Gryffindor',
  traits: ['courage', 'bravery']
};

const slytherin: House = {
  name: 'Slytherin',
  traits: ['ambition', 'leadership']
};

const ravenclaw: House = {
  name: 'Ravenclaw',
  traits: ['intelligence', 'learning']
};

const hufflepuff: House = {
  name: 'Hufflepuff',
  traits: ['hard work', 'patience']
};

const houses: House[] = [
  gryffindor,
  slytherin,
  ravenclaw,
  hufflepuff
];

I want to keep it simple, so the House type has only the name and the traits, a list of possible traits from people related to the house.

And then, I create each house and added all of them to the houses list.

Great! Now I'll build the Person type. A person can be a witch or a muggle.

type Witch = {
  name: string;
  trait: string;
    magicFamily: string;
}

type Muggle = {
  name: string;
    trait: string;
  email: string;
}

And this is the part we combine these two different types using the union type:

type Person = Muggle | Witch;

Using the intersection type, the Person type has all properties from Muggle or all from Witch.

So now, if I create a Muggle, I need just the name, the trait, and the email:

const hermione: Muggle = {
  name: 'Hermione Granger',
    trait: 'bravery',
  email: 'hermione@mail.com'
};

If I create a Witch, I need the name, the trait, and the magic family name:

const harry: Witch = {
  name: 'Harry Potter',
  trait: 'courage',
  magicFamily: 'Potter'
};

And if I create a Person, I need at least the name and the trait properties from Muggle and Witch:

const tk: Person = {
  name: 'TK',
  email: 'tk@mail.com',
  trait: 'learning',
  magicFamily: 'Kinoshita'
};

The chooseHouse is very simple. We just pas the houses and the person. Based on the person trait, the function will return the chosen house:

function chooseHouse(houses: House[], person: Person) {
  return houses.find((house) => house.traits.includes(person.trait))
}

And applying all the people we created:

chooseHouse(houses, harry); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, hermione); // { name: 'Gryffindor', traits: ['courage', 'bravery'] }
chooseHouse(houses, tk); // { name: 'Ravenclaw', traits: ['intelligence', 'learning'] }

Nice!

The intersection type is a bit different, but it can also be used to combine existing types.

When I was implementing a web app to apply my studies on UX, I needed to create a prop type for the Image component.

I had the type ImageUrl from the product type:

type ImageUrl = {
  imageUrl: string;
};

And the ImageAttr to represent all the attributes for the image:

type ImageAttr = {
  imageAlt: string;
  width?: string
};

But the props expected all this information in the component. Intersection type for the rescue!

type ImageProps = ImageUrl & ImageAttr;

Simple as that. So now, the component needs all these properties. The type looks like this:

type ImageProps = {
  imageUrl: string;
  imageAlt: string;
  width?: string
};

And we can use this type this way:

const imageProps: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
};

const imagePropsWithWidth: ImageProps = {
  imageUrl: 'www.image.com',
  imageAlt: 'an image',
  width: '100%'
};

Nice! One more concept to reuse and compose types.

I also find the Pick type very interesting and useful. We have other interesting types that we could write here, but the idea here is to understand that we can compose type and there is no limit to reuse types. If you're interested in study other types, take a look at this post I wrote: TypeScript Learnings: Interesting Types.

Tooling

When you npm install typescript, you don't just get the compiler, you get the language service API, a standalone server called tsserver that editors can run to provide autocompletion, go-to, and other cool features.

These features are what some people from the TypeScript team call developer productivity tools like smart errors when type checking and IntelliSense (code completion, hover info, signature information). We look at these features throughout the whole article, but I want to make a special topic to talk about it.

The TypeScript type checker is powerful in the sense that it can infer types and provide information to some possible issues. Example: It inferred that the city is a string. And the uppercase is used the wrong way. As it knows it is a string, it also tries to find a possible method that the engineer is looking for.

const city = 'Tokyo';
city.toUppercase();
// Property 'toUppercase' does not exist on type
// 'string'. Did you mean 'toUpperCase'?

In this case, the compiler is really smart, because it finds exatcly what we wanted.

It also works for objects:

const people = [
  { name: 'TK', age: 24 },
  { name: 'Kaio', age: 12 },
  { name: 'Kazumi', age: 31 },
];

for (const person of people) {
  console.log(person.agi);
  // Property 'agi' does not exist on type '{ name: string; age: number; }'
}

With the static types, the tooling can provide a great developer experience with code completion, hover info to show defined types, and signature information for methods and other data.

If you type: 'TK'., the editor will show all the possible methods for the string object. The compiler knows it is a string. And it knows the methods from the String prototype. But it also provides the method signature. This is very interesting because we don't necessarily need to go to the docs. The "docs" is already in our code editor.

It's an awesome experience while coding.

The type definition "on hover" is another thing that we saw earlier in this article. Let the compiler infer the types implicitly and you won't lose the type documentation. Using the hover in the object, the IDE or editor will always be able to show the type definition.

Another interesting thing is that TypeScript will not only flag what could go wrong on runtime, but it also helps to find code that doesn't do what you intend.

Imagine we have a function to open a snackbar if it is still closed. It would verify the status of the snackbar. If it is closed, just call another function to open it.

const buildSnackbar = (status: SnackbarStatus) => {
  if (status.isClosed) {
    openSnackbar();
  }
};

And the type information for this snackbar is:

type SnackbarStatus = {
  isClosed: boolean;
};

What happens if I call this function like this:

buildSnackbar({ isclosed: true });

It won't break in runtime, because the status object has no isClosed attribute and the undefined object is a falsy value, so it will skip the if condition and not call the openSnackbar function. No runtime error. But probably it will behavior different than the expected.

In TypeScript, the compiler will give some hints to make it works properly. First it will show this error:

// Argument of type '{ isclosed: boolean; }' is not assignable to
// parameter of type 'SnackbarStatus'.

isclosed with downcased C is not assignable to the type. It's not defined there. This is the first hint to make you correct your code.

The second is even better:

// Object literal may only specify known properties,
// but 'isclosed' does not exist in type 'SnackbarStatus'.
// Did you mean to write 'isClosed'?

It tells exactly what you probably need to do: rename the isclosed to isClosed.

We can talk a lot of things about the tooling about I think this is the main part.

My suggestion to learn more about this is to just code in TypeScript and "have a conversation" with the compiler. Read the errors. Play with the hover. See the autocompletion. Understand the method signatures. It's really a productive way to code.

Tips & Learnings

As the article is coming to an end, I want to just add some final thoughts, learnings, and tips to help you in your journey learning TypeScript or just applying it in your projects.

• Really read the type error: this will help you better understand the issue and the types.
• strictNullChecks and noImplicitAny can be very helpful in finding bugs. Enable this as soon as possible in your project. Use strictNullChecks to prevent “undefined is not an object”-style runtime errors. Use noImplicitAny to type the source code to give more type information for the compiler.
• Together with the compiler's configurations, I always recommend being very precise about your types. Mainly with the values that occur only in runtime like an API response. Correctness is important to catch as many bugs as possible in compile time.
• Understand the difference between runtime and compile time: types only affect in compile type. It runs the type checker and then compiles to JavaScript. The JavaScript source code doesn't use any type of references or type operations.
• Learn about utility types. We talked more specifically about the Readonly in the immutability in compile time, but TypeScript has a box of helpers like Required, Pick, and many more.
• If possible, prefer letting the compiler infers the types for you. Most of the types and returning types are redundant. The TypeScript compiler is very smart in this area. If not possible, you can always add type annotations. And leave the type assertions as the last option.
• As you're writing code, take a look at the tooling. The design of the tooling provided in an IDE is amazing. The IntelliSense and type checking provide a really good experience.

This post was originally published at TK's blog. And you can find more content like this in my blog at https://leandrotk.github.io/tk.

You can also follow me on Twitter and GitHub.

Resources

I compiled (pun very much intended!) a bunch of resources to help you learn more about programming languages, type systems, and the type mental model.

Also, if you found the examples on this post useful, I added all of them this repository: Thinking in Types. So you can fork and play with it.

Type Systems

• Type Compatibility
• Type Systems: Structural vs. Nominal typing explained
• Learning TypeScript: Structural vs nominal typing systems
• Constraints Liberate, Liberties Constrain — Runar Bjarnason
• Type Narrowing in TypeScript
• TypeScript: narrowing types via type guards and assertion functions
• TypeScript Learnings: Interesting Types

Tooling & Developer Experience

• Advanced TypeScript tooling at scale
• Type Systems & Props Design
• Anders Hejlsberg on Modern Compiler Construction
• TypeScript Compiler explained by the Author Anders Hejlsberg

Compile time vs Runtime

• Compile time vs Runtime
• Compile error vs Runtime error
• Value space and Type space
• A playground tool to play with TypeScript and see the JavaScript output

Best Practices

• TypeScript Best Practices
• Do's and Don'ts for General Types

Books

• Programming with Types Book
• Effective TypeScript: 62 Specific Ways to Improve Your TypeScript Book
• Thinking with Types

Have you wondered how to create a component in React?

To answer, it is as simple as creating a function returning an HTML-like syntax.

import React from 'react';

function Counter({n}) {
  return (
    <div>{n}</div>
  );
}

export default Counter;

Now let’s see what happened in the code above. Counter is a function that transforms a number into HTML. And if you look more carefully, Counter is a pure function. That’s right, the kind of function that returns the result based on its inputs and has no side-effects.

This explanation comes with a new question. What is a side-effect?

In short, a side-effect is any modification on the environment outside the function or any read information from the outside environment that can change.

You may have noticed that I used the destructuring assignment syntax in the parameter list to extract out the n input number. That’s because components take as input a single object called “props” that has all the properties sent to them.

Here is how the n parameter can be set from any other component:

<Counter n={1} />

In a sense, this syntax can be imagined like a function call Counter({n: 1}). Isn’t that right?

Let’s continue our journey.

Can functional components have state? As the component name suggested I want to store and change a counter. What if we just declare a variable holding a number inside the component? Will it work?

Let’s find out.

I will start by declaring the variable inside the functional component.

import React from 'react';

function Counter() {
  let n = 0;
  return (
    <div>{n}</div>
  );
}

export default Counter;

Now let’s add the function that increments the number and logs it to the console. I will use the function as the event handler for the click event.

import React from 'react';

function Counter() {
  let n = 0;

  function increment(){
    n = n + 1;
    console.log(n)
  }

  return (
      <div>
        <span>{n}</span>
        <button onClick={increment}>Increment </button>
      </div>
  );
}

export default Counter;