To run the examples in this book, you will need the following software, as well as basic understanding of how to use it:

• Docker version 18.06 or higher: https://www.docker.com/
• Git version 2.18.0 or higher: https://git-scm.com/

To run the samples:

1. Clone the https://github.com/PacktPublishing/Mastering-Functional-Programming repository on your machine.
2. From its root, compose and run the Docker set of images specified in docker-compose.yml. If you are on a Linux/Mac machine, you can run ./compose.sh to complete this step. If you are on Windows, open compose.sh in text editor and run each command from your terminal manually.
3. Run shell (Bash) on the Docker service called mastering-functional-programming_backend_1. You can complete this step by running ./start.sh on a Linux/Mac machine from a separate terminal window. If you are on a Windows machine, run docker exec -ti mastering_backend bash. Then cd Chapter1 for Chapter 1 examples, or cd ChapterN for Chapter N examples.
4. The cpp folder contains C++ sources. You can run them with ./run.sh <name-of-the-source> from that directory.
5. The jvm folder contains Java and Scala sources. You can run them by running sbt run from that directory.

Note that it is necessary to run the examples under Docker. Some chapters run examples against a live database, which is managed by Docker, so make sure to get the above procedure working.

The codes presented in this book are available at: https://github.com/PacktPublishing/Mastering-Functional-Programming

Why declarative programming? How did it appear? To understand declarative programming, we need to first understand how it is different from imperative programming. For a long time, imperative programming has been a de facto industry standard. What motivated people to start switching to the functional style from the imperative style?

In imperative programming, you rely on a set of primitives that your language provides. You combine them in a certain way so as to achieve a functionality that you need. We can understand different things under primitives. For example, these can be loop control structures, or, in the case of collections, operations specific to collections, such as creating a collection and adding or removing elements from a collection.

In declarative programming, you also rely on primitives. You use them to express your program. Yet, in declarative programming, these primitives are much closer to your domain. They can be so close to your domain that the language itself can be regarded as a domain-specific language (DSL). With declarative programming, you are able to create primitives as you go.

In imperative programming, you usually don't create new primitives, but rely on the ones the language provides you with. Let's go through some examples to understand the importance of declarative programming.

How imperative turns into declarative is best understood by means of an example. Most likely, you already know the go-to statement. You have heard that using the go-to statement is bad practice. Why? Consider an example of a loop. It is possible to express a loop using only the go-to statement:

#include <iostream>
using namespace std;
int main() {
  int x = 0;    
  loop_start:
   x++;
  cout << x << "\n";
  if (x < 10) goto loop_start;
  return 0;
}

From the preceding example, imagine you need to express a while loop. You have the variable x and you need to increment it in a loop by one until it reaches 10. In modern languages such as Java, you would be able to do this using the while loop, but it is also possible to do that using the go-to statement. For example, it is possible to have a label on the increment statement. A conditional statement after it will check whether the variable reached the necessary value. If it did not, we perform a go-to on the line of code to increment a variable.

Why is go-to a bad style in this case? A loop is a pattern. A pattern is an arrangement of two or more logical elements in your code that repeats in different places of your program. In our case, the pattern is the loop. Why is it a pattern? First, it consists of three parts:

1. The first part is the label that is the entry point to the body of the loop—the point where you jump from the end of the loop to reiterate the loop.
2. The second part is the condition that must be true in order for the loop to reiterate.
3. The third part is the statement to reiterate the fact that it is a loop. It is the end of the body of the loop.

Besides being composed of three parts, it also describes an action that is ubiquitous in programming. The action is repeating a chunk of code more than once. The fact that loops are ubiquitous in programming needs no explanation.

If you re-implement the loop pattern each time you need it, things can go wrong. As the pattern has more than one part to it, it can be corrupted by misusing one of the parts, or you could make a mistake when arranging the parts into a whole. It is possible to forget to name the label to which to jump, or to name it incorrectly. You may also forget to define the predicate statement that guards the jump to the beginning of the loop. Or, you could misspell the label to which to jump in the q statement itself. For example, in the following code, we forgot to specify the predicate guard:

int main() {
 int x = 0;
 loop_start:
  x++;
 cout << x << "\n";
 goto loop_start;
 return 0;
}

It's pretty hard to get such a simple example wrong, but consider a nested loop. For example, you have a matrix, and you want to output it to the console. This can be done with a nested loop. You have a loop to iterate on with every entry of the 2D array. Another loop nested in that loop examines the row the outer loop is currently working on. It iterates on every element of that row and prints it to the console.

It is also possible to express these in terms of the go-to statement. So, you will have the first label to signify the entry point into the large loop, another label to signify the entry point to the small loop, and you will call the go-to statement at the end of each loop to jump to the beginning of the respective loop.

Let's see how to do that. First, let's define a 2D array as follows:

 int rows = 3;
 int cols = 3;
 int matrix[rows][cols] = {
   { 1, 2, 3 },
   { 4, 5, 6 },
   { 7, 8, 9 }
 };

Now, we can loop over it as follows:

 int r = 0;
 row_loop:
 if (r < rows) {
  int c = 0;
   col_loop:
   if (c < cols) {
  cout << matrix[r][c] << " ";
     c++;
     goto col_loop;
   }
   cout << "\n";
   r++;
   goto row_loop;
 } return 0;}

You can already see an increase in complexity here. For example, you can perform a go-to from the end of the inner loop to the beginning of the outer loop. This way, only the first item of each column receives output. The program becomes an infinite loop:

 int r = 0;
 row_loop:
 if (r < rows) {
   int c = 0;
  col_loop:
  if (c < cols) {
    cout << matrix[r][c] << " ";
     c++; 
    goto row_loop;
  }
  cout << "\n";
   r++;
   goto row_loop;
 }

One of the fundamental rules of engineering is to create abstractions for logic that repeats. The pattern of the loop is ubiquitous. You can experience it in almost any program. Hence, it is reasonable to abstract away. This is why contemporary languages, such as Java or C++, have their own built-in mechanisms for loops.

The difference it makes is that, now, the entire pattern consists of one component only, that is, the keyword that must be used with a certain syntax:

#include <iostream>
using namespace std;
int main() {
  int rows = 3;
  int cols = 3;
  int matrix[rows][cols] = {
    { 1, 2, 3 },
    { 4, 5, 6 },
    { 7, 8, 9 }
  };
  for (int r = 0; r < rows; r++) {
    for (int c = 0; c < cols; c++) cout << matrix[r][c] << " ";
    cout << "\n";
  }
}

What happened here is that we gave a name to the pattern. Every time we need this pattern, we do not implement it from scratch. We call the pattern by its name.

This calling by name is the main principle of declarative programming: implement patterns that repeat only once, give names to those patterns, and then refer to them by their name anywhere we need them.

For example, while or for loops are patterns of loops. They are abstracted away and implemented on a language level. The programmer can refer to them by their names whenever they need a loop. Now, the chance of making an error is much less likely because the compiler is aware of the pattern. It will perform a compile-time check on whether you are using the pattern properly. For example, when you use the while statement, the compiler will check whether you have provided a proper condition. It will perform all the jump logic for you.

So, you do not need to worry whether you jumped to the correct label, or that you forgot to jump at all. Therefore, there is no chance of you jumping from the end of the inner loop to the start of the outer loop.

What you have seen here is the transition from an imperative to a declarative style. The concept you need to understand here is that we made the programming language aware of a certain pattern. The compiler was forced to verify the correctness of the pattern at compile time. We specified the pattern once. We gave it a name. We made the programming language enforce certain constraints on the programmer that uses this name. At the same time, the programming language takes care of the implementation of the pattern, meaning that the programmer does not need to be concerned with all the algorithms that were used to implement the pattern.

So, in declarative programming, we specify what needs to be done without specifying how to do it. We notice patterns and give them names. We implement these patterns once and call them by name afterward whenever we need to use them. In fact, modern languages, such as Java, Scala, Python, or Haskell do not have the support of the go-to statement. It seems that the vast majority of the programs expressed with the go-to statement can be translated into a set of patterns, such as loops, that abstract away go-to statements. Programmers are encouraged to use these higher-level patterns by name, rather than implementing the logic by themselves using lower-level go-to primitives. Next, let's see how this idea develops further using the example of declarative collections and how they differ from imperative ones.

Another great illustration of how the declarative style works can be seen in collection frameworks. Let's compare the collection frameworks of an imperative and functional programming language, for example, Java (imperative) collections and Scala (functional) collections.

Why a collection framework? Collections are ubiquitous in any programming project. When you are dealing with a database-powered application, you are using collections. When you are writing a web crawler, you are using collections. In fact, when you are dealing with simple strings of text, you are using collections. Most modern programming languages provide you with the implementation of collection frameworks as part of their core library. That is because you will need them for almost any project.

We'll go into more depth about how imperative collections are different from declarative collections in the next chapter. However, for the purpose of an overview, let's briefly discuss one of the major differences between the imperative and declarative approaches to collections here. We can see such a difference using the example of filtering. Filtering is an ubiquitous operation that you most likely will find yourself doing pretty often, so let's see how it differs across the two approaches.

Java is a classic example of a very imperative approach to programming. And hence, in its collections, you will encounter operations that are typical of imperative programming. For example, consider that you have an array of strings. They are the names of the employees of your company. You want to create a separate collection with only those employees whose names start with the letter 'A'. How do you do that in Java?

// Source collection
List<String> employees = new ArrayList<String>();
employees.add("Ann");
employees.add("John");
employees.add("Amos");
employees.add("Jack");
// Those employees with their names starting with 'A'
List<String> result = new ArrayList<String>();
for (String e: employees)
  if (e.charAt(0) == 'A') result.add(e);
   System.out.println(result);

First, you need to create a separate collection to store the result of your computation. So, we create a new ArrayList of strings. Afterward, you will need to check every employee's name to establish whether it starts with the letter 'A'. If it does, add this name to the newly created array.

What could possibly go wrong? The first issue is the very collection where you want to store your results. You need to call result.add() on the collection – but what if you have several collections, and you add to the wrong one? You have the freedom to add to any collection at that line of code, so it is conceivable that you add to the wrong one – not the dedicated one you have created solely for the purpose of filtering the employees.

Another thing that can go wrong here is that you can forget to write the if statement in the large loop. Of course, it is not very likely in such a trivial example, but remember that large projects can bloat and code bases can become large. In our example, the body of the loop has fewer than 10 lines. But what if you have a code base where the for loop is up to 50 lines, for example? It is not as obvious there that you won't forget to write your predicate, or to add the string to any collection at all.

The point here is that we have the same situation as in the loop versus go-to example. We have a pattern of an operation over a collection that might repeat itself in the code base. The pattern is something that is composed of more than one element, and it goes as follows. Firstly, we create a new collection to store the result of our computation. Secondly, we have the loop that iterates on every element of our collection. And finally, we have a predicate. If it is true, we save the current element into the result collection.

We can imagine the same logic executed in other contexts as well. For example, we can have a collection of numbers and want to take only those that are greater than 10. Or, we can have a list of all our website users and want to take the age of those users visiting the site over a particular year.

The particular pattern we were discussing is called the filter pattern. In Scala, every collection supports a method defined on it that abstracts away the filter pattern. This is done as follows:

// Source collection
val employees = List(
  "Ann"
, "John"
, "Amos"
, "Jack")
// Those employees with their names starting with 'A'
val result = employees.filter ( e => e(0) == 'A' )
println(result)

Notice that the operation remains the same. We need to create a new collection, then incorporate the elements from the old collection into the new collection based on some predicate. Yet, in the case of the pure Java solution, we need to perform three separate actions to get the desired result. However, in the case of the Scala declarative style, we only need to specify a single action: the name of the pattern. The pattern is implemented in the language internals, and we do not need to worry about how it is done. We have a precise specification of how it works and of what it does, and we can rely on it.

The advantage here is not only that the code becomes easier to read, and thus easier to reason about. It also increases reliability and runtime performance. The reason is that the filter pattern here is a member of the core Scala library. This means that it is well tested. It was used in a large number of other projects before. The subtle bugs that could have existed in such a situation were likely caught and fixed.

Also observe that the notion of anonymous lambdas gets introduced here. We pass one as an argument to the filter method. They are functions that are defined inline, without the usual tedious method syntax. Anonymous lambdas are a common feature of functional languages, as they increase your flexibility for abstracting logic.

In other modern languages, such as Haskell or Python, a similar declarative functionality is also present out of the box. For example, you can perform filtering in Python—it is built into the language, and you have a special function in Haskell to perform the same filtering. Also, the functional nature of Python and Haskell makes it easy to implement the same control structure as filtering by yourself. Both Haskell and Python support the notion of the lambda function and higher-order functions, so they can be used to implement declarative control structures.

In general, you can spot whether a language is declarative programming-friendly by looking at the capabilities it provides. Some of the features you can look for are anonymous functions, functions as first-class citizens, and custom operator specifications.

Anonymous lambda gives you a great advantage because you can pass functions to other functions inline, without first defining them. This is particularly useful when specifying control structures. A function expressed in this way is, first and foremost, to specify a transformation that is supposed to transform an input into an output.

Another feature that you can look for in programming languages is support for functions as first-class citizens. This means that you are able to assign a function to a variable, refer to the function by that variable's name, and pass that variable to other functions. Treating functions as if they are ordinary variables allows you to achieve a new level of abstraction. This is because functions are transformations; they map their input values to some output values. And, if the language does not allow you to pass transformations to other transformations, this is a limitation of flexibility.

Another feature that you can expect from declarative languages is that they allow you to create custom operators; for example, the synthetic sugar available in Scala allows you to define new operators very easily, as methods in classes.

The declarative style is a style of programming where you call the operations you want to perform by name, instead of describing how to execute them in an algorithmic fashion via lower-level primitives provided by the programming language. This naturally aligns with the DRY principle. If you have a repeating operation, you want to abstract it away, and then refer to it by name later on. In other words, you need to declare that the operation has a certain name. And, whenever you want to use it, you need to declare your intent, without specifying directly how it should be fulfilled.

Modern functional programming goes hand in hand with the declarative style. Functional programming provides you with a better level of abstraction, which can be used to abstract away the repeating operations.

In the next chapter, we will see how first-class citizen support for functions can be useful for the declarative programming style.

1. What is the principle behind declarative programming?
2. What does DRY stand for?
3. Why is using go-to bad style?