So what are functions? We can define them as parameterized, named chunks of code. This means that they are chunks of code that can be called from any other part of the program by their name. Parameterized means that you can call them with certain arguments. Different calls executed with different parameters usually lead to different results.

What is the motivation behind functions? The answer is the basic principle of engineering – abstract away that which repeats itself. In Chapter 1, The Declarative Programming Style, we saw something similar in the case of loops. However, loops are built-in control structures. This means they are defined at the language level. When we need to define some logic on the language-user level, and this logic repeats itself across different parts of the project, functions come into play.

We can trace functions across...

In imperative programming, functions are used to represent the behavior of an object. In object-oriented programming, the behavior usually implies side effects. For the purposes of this book, we can understand side effects as follows—a function is side-effecting when it modifies the environment outside its own body. For example, it can have a global variable of its parent object modified, it can write a file into the filesystem, or the function can perform some web API calls over the network.

In functional programming, the understanding of functions is quite different. In functional programming, we prise purity and referential transparency. Purity means the absence of side effects. Referential transparency means that the result value the function has computed can be substituted in place of the function call, while the semantics of the...

Another important concept that appears in functional programming is that of higher-order functions. A higher-order function is a function that accepts a function as an argument. A very trivial example of where this may be useful is control structures. For example, a while loop can be expressed in a functional way as a higher-order function that accepts the body of the loop and a predicate as an argument.

The body of the loop can be expressed as a function that does not accept any arguments, but computes some side effects. The way it works is that we have a function accept a 0-argument function and a predicate, and we call the same loop function recursively while the predicate is true.

We can call the new control structure whileDiy, and it can be defined as follows:

@annotation.tailrec
def whileDiy(predicate: => Boolean)(body: => Unit): Unit =
  if ...

Most functional languages have a concept of a lambda function. It is an anonymous function defined inline. It can be assigned to a variable if needed. For example, consider that we need a function that accepts a cookie with user session data, in the context of a web application. Its job is to print a greeting to the user to the standard output. However, before printing, we need to decorate the user's name in a certain way. To complicate matters further, we also have a database of users who hold PhDs and, if they do, we need to refer to them as Dr. Here is how it can be done in Scala:

1. We define the dummy Cookie class for our example:

case class Cookie(name: String, gender: String)

2. We define the greeting method. The job of the method is to extract the data from the cookie object, and apply the modifier to the user's name based on their...

Functions are present in many programming languages. Some of the languages have better support for purely functional styles, while others favor declarative styles. This is why, for example, using Scala over Java can give you tremendous leverage, because you can declare functions inside other functions, you can declare functions that accept other functions (higher-order functions) more easily, and you can declare anonymous lambda functions (functionality also available in Java, starting from Java 8). This greatly increases your capacity for abstraction, creating control structures, and thereby enabling your application to be expressed in a more DRY (Don't Repeat Yourself) way.

In this chapter, we have seen what functions are and how they have evolved from the early days of programming to today. We have seen how functions were initially treated as abstractions of common logic. After that, in object-oriented programming, they represented the behavior of certain objects. Object-oriented programmers attempted to represent everything as an object. So it is only natural that functions started to be viewed in the context of a world that consists of objects. In this context, functions are best viewed as behaviors of these objects.

In functional programming, functions can be viewed in a different context. Now, the best way to view functions is as mathematical computations. They compute some value out of its inputs, in a pure way, which means without any side effects. The idea is to view them as mathematical functions.

Functional programming is close...

1. How are functions interpreted in the context of object-oriented programming?
2. How are functions interpreted in the context of pure functional programming?
3. What are higher-order functions?
4. Why are higher-order functions useful?