Functional programming is a paradigm (a style of structuring your programs). In essence, the focus is on transforming data with expressions (ideally such expressions should not have side effects). Its name, functional, is based on the concept of a mathematical function (not in sub-routines, methods, or procedures). A mathematical function defines a relation between a set of inputs and outputs. Each input has just one output. For example, given a function, f(x) = X²; f(5) is always 25.

The way to guarantee, in a programming language, that calling a function with a parameter always returns the same value, is to avoid accessing to mutable state:

fun f(x: Long) : Long { 
   return x * x // no access to external state
}

The f function doesn't access any external state; therefore, calling f(5) will always return 25:

fun main(args: Array<String...

Functional programming is composed of a few well-defined concepts. A short introduction of these concepts will follow and, later on, each concept will be covered in depth, in the next chapters.

The most foundational concept of functional programming is first-class functions. A programming language with support for first-class functions will treat functions as any other type; such languages will allow you to use functions as variables, parameters, returns, generalization types, and so on. Speaking of parameters and returns, a function that uses or returns other functions is a higher-order function.

Kotlin has support for both concepts.

Let's try a simple function ...

Functional collections are collections that offer a way to interact with its elements through high-order functions. Functional collections have common operations with names such as filter, map, and fold; these names are defined by convention (similar to a design pattern) and are being implemented in several libraries and languages.

Don't get confused with purely functional data structures—a data structure implemented in a pure functional language. A purely functional data structure is immutable and uses the lazy evaluation and other functional techniques.

Functional collections can but needn't necessarily be purely functional data structures. We have already covered how imperative implementations of algorithms can be faster than functional ones. 

Kotlin comes with an excellent functional collection library. Let's have a look at...

With everything that we've learned in the first two chapters, we can implement a pure functional list:

sealed class FunList<out T> {
   object Nil : FunList<Nothing>()

   data class Cons<out T>(val head: T, val tail: FunList<T>) : FunList<T>()
}

The FunList class is a sealed class; just two possible subclasses exist—Nil, an empty list (in other books you can see this defined as Null or Empty) and Cons (a construct, name inherited from Lisp, that holds two values).

The T type is marked out; this is for variance, which we'll cover variance in future chapters.

Nil is an object (we don't need different instances of Nil) extending FunList<Nothing> (remember that Nothing is the bottom of Kotlin's type hierarchy).

The Cons value contains two values—head, a single T, and...

In this chapter, we covered the basics of functional programming, including high-order functions, pure functions, recursion functions, and lazy evaluation. We also covered functional collections and we implemented a functional collection, using a functional programming style.

In the next chapter, we'll cover a foundational stone of functional programming—immutability.