Differences from other programming paradigms

The main difference between the functional programming paradigm and other paradigms is that functional programs use math functions rather than statements to express ideas. So instead of writing a precise set of steps to solve a problem, you use math functions, and you don’t worry about how the language performs the task. In some ways, this approach makes languages that support the functional programming paradigm similar to applications such as MATLAB, which is used to perform various kinds of high level, complex math computations. With MATLAB, you get a user interface, which reduces the learning curve. But you pay for the convenience of the user interface with a loss of power and flexibility, which functional languages do offer. Using the functional approach to defining a problem relies on the declarative programming style, which you see used with other paradigms and languages, such as Structured Query Language (SQL) for database management.

In contrast to other paradigms, the functional programming paradigm doesn’t maintain state. The use of state enables you to track values between function calls. Other paradigms use state to produce variant results (output that changes) based on environment, such as to determine the number of existing objects and to do something different when the number of objects is zero. But because functional programs don’t maintain state, calling a functional program function always produces the same result when you have a particular set of inputs. Functional programs are therefore more predictable than those that support state.

Because functional programs don’t maintain state, the data they work with is also immutable, which means that you can’t change it. To change a variable’s value, you must create a new variable. Again, this feature makes functional programs more predictable than other approaches and could make functional programs easier to run on multiple processors.

Understanding its goals

Imperative programming, the kind of programming that most developers have done until now, is akin to an assembly line, where data moves through a series of steps in a specific order to produce a particular result. The process is fixed and rigid, and the person implementing the process must build a new assembly line every time an application requires a new result. Object-oriented programming (OOP) simply modularizes and hides the steps, but the underlying paradigm still works on that assembly-line idea. Even with modularization, OOP often doesn’t allow rearrangement of the object code in unanticipated ways because of the underlying interdependencies of the code.

Functional programming gets rid of the interdependencies by replacing procedures with pure functions, which require the use of immutable state. The assembly line is no more. An application can manipulate data using the same means as those used in pure math. The seeming restriction of immutable state lets anyone who understands the math of a situation also create an application to perform the math.

Using pure functions creates a flexible environment in which code order depends on the underlying math. That math models a real-world environment, and as the human understanding of that environment changes and evolves, the math model and functional code can change with it — without the usual problems of brittleness that cause imperative code to fail. Modifying functional code is faster and less error prone than using other paradigms because the person implementing the change must understand only the math; there’s no need to know how the underlying code works. In addition, learning how to create functional code can be faster as long as the person understands the math model and its relationship to the real world.

Functional programming also embraces a number of unique coding approaches, such as the capability to pass a function to another function as input. This capability enables you to change application behavior in a predictable manner that isn’t possible using other programming paradigms.

Using the pure approach

Programming languages that use the pure approach to the functional programming paradigm rely on lambda calculus principles, for the most part. In addition, a pure-approach language allows the use of functional programming techniques only, so the result is always a functional program. Haskell is probably the most popular pure language because it provides the purest implementation and is generally a relatively popular language, according to the TIOBE index (https://www.tiobe.com/tiobe-index/). Other pure-approach languages include Lisp, Racket, Erlang, and OCaml.

When considering functional programming, especially in the pure sense, a language must meet these requirements:

• It uses pure functions. A pure function always produces precisely the same result for a given set of inputs. Also, a pure function doesn’t modify any global variables or any input arguments. Pure functions are extremely easy to debug because they have no side effects; nothing is hidden. Plus, a compiler can do things like memorize the results of a pure function call because such calls never change, and the compiler can wait to calculate results until they’re actually needed. When working with a pure function, you can
  • Remove the function if no other functions rely on its output.
  • Reverse the order of calls to different functions without any change to application functionality.
  • Process the function calls in parallel without any consequence.
  • Evaluate the function calls in any order, assuming that the entire language doesn’t allow side effects.
• It relies on recursion. There are no for, while, do, or any other sort of looping mechanisms in a functional language. Instead, a functional language relies on recursion because recursion doesn’t require state (a counter variable as a minimum) to complete a looping task.
• It uses referential transparency. The language uses no assignment statements. The value of a variable is replaceable with its actual value at any point in the program. If a new value needs to be stored, the environment creates a new variable to do it.
• Its functions are first class and can be higher order. A first-class function can act as a variable and you can pass it to any function requiring an argument. In addition, a function can return a first-class function instead of a value. Higher-order functions can accept other functions as input and output functions as results.
• Its variables are immutable. The value of something can’t change, so you can always rely on it to be the same value. This means you can create a variable in one place and use its value in another place without ever worrying about the value of the variable changing.

As with many elements of programming, people have strong opinions about whether a particular programming language qualifies for pure status. For example, many people consider JavaScript to be a pure language, even though it’s untyped. Others feel that domain-specific declarative languages such as SQL and Lex/Yacc qualify for pure status even though they aren’t general programming languages. Simply having elements of functional programming doesn’t mean that a language adheres to the pure approach.

Using the impure approach

Many developers have come to see the benefits of functional programming. However, they also don’t want to give up the benefits of their existing language, so they use a language that mixes functional features with one of the other programming paradigms (as described in the “Comparing the Functional Paradigm” section that follows). For example, you can find a few functional programming features in languages such as C++, C#, and Java.

Adding functional features to an existing language rarely results in a good mix of functional features because the additions have too many compromises. When you work with an impure language, you need to be careful because your code won’t work in a purely functional manner, and the features that you might think will work in one way actually work in another. For example, you can't pass a function to another function in some languages, but doing so is a requirement for functional programming.

Languages such as Kotlin and Python are designed from the outset to support multiple programming paradigms. In fact, some online courses make a point of teaching this particular aspect of Kotlin as a special benefit (see https://functionalkotlin.com/). The use of multiple programming paradigms makes Kotlin quite flexible but also leads to complaints and apologists. This chapter relies on Kotlin to demonstrate the impure approach to functional programming because it’s both popular and flexible, plus it’s easy to learn.

Relying on standard recursion

When using recursion to solve a problem, you normally start with something complex that can be divided into a simple case. For example, when you calculate a factorial, 1!, is the simplest case because it has a value of 1. So, this simple case is n = 1. The next case is a little harder; now you must multiply 1 * 2 to obtain the result, so this next case is n = 1 * 2. Instead of just one step, you now have two steps. Each case becomes progressively more difficult, with 3 being the next case: n = 1 * 2 * 3. So, recursion rests on dividing the problem into simple steps until you reach the simplest case.

The reason recursion works for the factorial problem is that you can create this reduction in complexity by having the function call itself as often as needed to reach the simplest case of n = 1. (If you want to play with the code that follows and in other areas of this chapter without having to start Android Studio, you can use an online interpreter, such as the one at https://try.kotlinlang.org/.) Here is the Kotlin code to perform this task:

fun main(args: Array<String>) {
println(factorial(5))
}

fun factorial(n: Int): Int {
if (n == 1){
println("Ended")
} else {
println("Handling n = $n")
var value = n * factorial(n - 1)
println("Value = $value")
return value
}

return n
}

This code contains a number of println() statements so that you can better understand how the recursion works. Normally, this code could be extremely short:

fun fact(n: Int): Int {
return if (n==1) n else n * fact(n - 1)
}

You could even make it shorter still, but really, it's short enough. The output from the wordy version looks like this:

Handling n = 5
Handling n = 4
Handling n = 3
Handling n = 2
Ended
Value = 2
Value = 6
Value = 24
Value = 120
120

The factorial() function keeps calling itself until it reaches the simplest case, n == 1. However, it doesn't finish anything. It doesn’t get to the next step, which is var value = n * factorial(n - 1). At each step, the code pushes the current iteration onto the stack (think of a stack of pancakes, except we’re talking memory here) and then it calls the next iteration and finally reaches n == 1. This is why you see each of the Handling n = statements as output without any value statements.

At this point, the procedure for n == 1 finishes and this iteration, n == 1, is popped from the stack, which means the next iteration, n == 2 * 1, can complete. This is why you see an output of Value = 2. Each iteration completes and is popped from the stack in turn, until, finally, nothing is left to return and the factorial() function returns the value of n == 5 * 4 * 3 * 2 * 1, which is 120.

The main benefit of this approach to recursion is that it works on every kind of problem. Developers have used this form of recursion for years with every language imaginable, so it's hardly an earth-shaking approach to dazzle your friends. Consider this the tried-and-true approach to recursion.

Relying on tail recursion

You might wonder why someone would need a second form of recursion given that standard recursion will work on every problem. The fact is that standard recursion has certain problems that you can solve using this second form, which is called tail recursion because there is nothing to do after the last step of the recursion process. Using tail recursion has these advantages:

• It executes faster because it doesn’t rely on stack pushes and pops to maintain the previous iteration.
• Recursion can occur infinitely because no stack resources are used (so there is no chance of running out of memory due to the recursion).
• It eliminates the potential for StackOverflow exceptions.

You have a few ways to handle tail recursion. Some don’t work with every problem, but you can take a look at a general approach before delving into other approaches. Here is a version of the factorial problem using tail recursion (use the main() function from the “Relying on standard recursion” section to execute both factorial2() and factorial3()):

fun factorial2(n: Int, acc: Int = 1): Int {
if (n == 1) {
println("Ended with n = $n, acc = $acc")
return acc
}

println("Handling n = $n, acc = $acc")
return factorial2(n - 1, acc * n)
}

In this case, the code relies on an accumulator, acc, to track the current value. Notice that the recursive call occurs at the tail — the end — of the process. The actual process is similar, but you won't encounter stack problems using this approach. Here is the output from this version of the example:

Handling n = 5, acc = 1
Handling n = 4, acc = 5
Handling n = 3, acc = 20
Handling n = 2, acc = 60
Ended with n = 1, acc = 120
120

The only problem with factorial2() is that it hasn’t been optimized to use tail recursion. You won’t actually see this optimization as part of the code (you write it the same way), but you need to tell Kotlin to perform the optimization for you using the tailrec keyword. Here is a final version that won't suffer from stack overflows and works quite fast:

tailrec fun factorial3(n: Int, acc: Int = 1): Int {
return if (n == 1) acc else factorial3(n - 1, acc * n)
}

The only problem with tail recursion is that it won’t work with every problem. You need to validate the results of any recursion you perform using this approach to ensure that you’re getting the correct output.

Lambda expressions

A lambda expression is an expression that you assign to a variable. You can make the assignment directly, or you can make the assignment to a function argument. Here's an example of a lambda expression assigned to a variable:

val doAdd = {a: Int, b: Int -> a.toDouble() + b}
println(doAdd(1, 2))

You can also supply a lambda expression as input to a function that expects a function as input. Consider these string manipulation examples:

fun main(args: Array<String>) {
val repeat: String.(Int) -> String =
{times -> this.repeat(times)}
val part: String.(Int) -> String =
{len -> this.take(len)}

println(changeString(repeat, "A String ", 4))
println(changeString(part, "A String ", 4))
}

fun changeString(function: (String, Int) -> String,
string: String, number: Int): String {
return function(string, number)
}

This example has two different string manipulation lambda functions with an important change from the previous example. Notice the String.(Int) part of the declaration. The String is referenced as the this argument in the lambda function. So, this.repeat or this.take refers to the String that is supplied as input. Using this technique can make your coding easier at times.

Another difference is that this example provides an expression signature so that it's clear what the expression requires as input. Normally, the compiler automatically detects the signature, but defining one doesn’t hurt. The repeat signature of String.(Int) -> String states that the expression needs a String that is used for this, along with an Int, and it outputs a String.

Notice that only the Int appears as an argument to the expression in the form of times: {times -> this.repeat(times)}. When working with a lambda expression of this sort, developers have a tendency to provide too many or too few inputs to the expression.

The function, changeString(), works differently depending on the lambda expression you provide. Using this approach means that you can write a single function that performs what is essentially a boilerplate task of manipulating a string, but it can change the behavior of the function based on what you need at any given time. As long as the signature of the function matches the signature of the lambda expression, the function will work as anticipated.

Anonymous functions

An anonymous function is simply a function that lacks a name. You use anonymous functions in many of the same places as you do lambda expressions. In many cases, the choice between the two comes down to a combination of personal preference and clarity of expression. Even though the two forms of expression obtain the same result in most cases, the way you construct the expression differs, so one form might be clearer in some cases than the other is.

Aside from the need to declare an anonymous function as a function (despite it acting like an expression), an anonymous function also differs from a lambda expression in one important way: You can provide a return type with an anonymous function.

The previous section shows how to use multiple lambda expressions with a single function, changeString(). You can perform the same task using an anonymous function, as shown here:

fun main(args: Array<String>) {
val repeat = fun(inStr: String, times: Int): String {
return inStr.repeat(times)
}
val part = fun(inStr: String, len: Int): String {
return inStr.take(len)
}

println(changeString(repeat, "A String ", 4))
println(changeString(part, "A String ", 4))
}

fun changeString(function: (String, Int) -> String,
string: String, number: Int): String {
return function(string, number)
}

Notice that changeString() hasn't changed at all, and this is the amazing thing about being able to use either a lambda expression or an anonymous function. The function receiving either form doesn’t change, which means that even when you provide expressions to Kotlin or Android functions, you still have a choice as to which form to use for your particular need.

The anonymous function looks like any other function you might have created in the past, except for the lack of a name. You can create a function body of any size needed to complete the task, so anonymous functions often work better than lambda expressions when performing a complex set of steps within the function body.

Comprehensions

A comprehension is a kind of manipulation you perform on a List, Set, or Map to understand it in a certain way. These comprehensions are listed as part of the extension functions for a collection, such as those shown for List at https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/-list/index.html. To differentiate a comprehension from another sort of extension function, look at the input, which is normally a predicate or transform, and the output, which is normally a subset of the current List.

A comprehension begins with the original List, followed by the dot-separated list of comprehension functions. Here's an example of a numeric comprehension that returns only the values that meet a specific criterion and transforms them into strings:

val numbers = listOf(1, 2, 3, 4, 5)
val selection = numbers
.filter {it >= 3}
.map {"Value = $it"}

selection.forEach({println(it)})

Placing each comprehension on its own line tends to make the entire expression easier to read. In this case, the filter() function returns only those numbers elements that are equal to or greater than 3. It then calls on map() to transform the numbers into a specifically formatted string. Each function works on the input List in the order in which it appears, so order is important in defining how the comprehension works.

Whenever you work with comprehensions, it represents the collection as it appears from the previous step. So, in .filter {it >= 3}, it represents the original List found in numbers. However, in .map {"Value = $it"}, it represents the modified List from the filter step. Here's the output from this example:

Value = 3
Value = 4
Value = 5

Receivers

A receiver is a kind of member addition to a class made outside the class proper. You use a receiver as the start of an extension function that makes the class able to do more than it otherwise could without actually modifying the class itself or creating a new subclass. The receiver consists of a signature followed by a lambda expression. Here is a simple example:

class Name (val aName: String)

fun main(args: Array<String>) {
val greet: Name.() -> String =
{"Hello ${this.aName}!"}

val person = Name("George")

println(person.greet())
}

The example begins with the Name class, which takes a String argument, aName, as part of its primary constructor. The receiver, greet, references the Name class and provides an extension to it (as designated by the period) that requires no arguments (as shown by the empty parentheses). The lambda expression outputs a string that includes the content of aName. Note that you must reference aName using this.aName.

To use the extension, you create a new object, person, and provide a value of "George" to aName. The call to println() displays the greeting Hello George! by calling person.greet().

You can further extend this example by providing a specific greeting, rather than simply Hello. This update allows the addition of a greeting:

val greet: Name.(String) -> String =
{"$it ${this.aName}!"}

val person = Name("George")

println(person.greet("Good morning"))

In this case, you specify a String input argument for greet(). A receiver can only have one input parameter. You reference this input argument using it within the lambda expression code. In addition, when calling greet(), you must now supply the input argument. Consequently, this version of the code outputs: Good morning George!.

One of the reasons that knowing how to use receivers and extension functions is so important is that some Kotlin classes and functions use them. For example, even though you're usually not likely to write code like this, you could create a complex StringBuilder object using this approach:

val aGreeting = StringBuilder("Hello ")
.apply {
append("there ")
append("from Kotlin!")
}.toString()

println(aGreeting)

The apply() inline function accepts a series of inputs to modify the original StringBuilder input using the append() extension function. You can see a list of other StringBuilder extension functions at https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/-string-builder/index.html. The output of this example is Hello there from Kotlin!.

Inline

When you create lambda expressions, anonymous functions, standard functions, and other kinds of modularized code, the code resides in a separate area of memory. To use the code, the compiler must create a connection to it, which adds overhead to the application. If you call this modularized code many times, the overhead can significantly slow your application, but at the same time, because the code exists in just one place, you don't use any additional memory. On the other hand, if you were to repeat the modularized code everywhere you need it, application performance would improve, but at the cost of memory. (Not only that, but by repeating the code all over the place you make code modifications a nightmare!)

A way around the performance issue is to use the inline keyword to tell the compiler to inline the code — that is, to place the compiled version of the code directly where the application needs it. For example, you could inline this code:

fun main(args: Array<String>) {
val repeat = fun(inStr: String, times: Int): String {
return inStr.repeat(times)
}
val part = fun(inStr: String, len: Int): String {
return inStr.take(len)
}

println(changeString(repeat, "A String ", 4))
println(changeString(part, "A String ", 4))
}

inline fun changeString(function: (String, Int) -> String,
string: String, number: Int): String {
return function(string, number)
}

When you inline the code like this, the println() calls change. What the compiled version does looks like this:

println(("A String ").repeat(4))
println(("A String ").take(4))

Utility

Kotlin provides a number of utility functions that make dealing with potentially null values a lot easier. In some cases, you use them to manipulate values in such a manner that potentially null results aren't a problem. Here is a list of utility functions that you should keep in mind:

• run(): Enables you to work with potentially null values and pass non-null values to functions that can’t accept a null value. Here’s an example of run() in use:

  fun main(args: Array<String>) {
val myInt: Int? = null
val result = myInt?.run {greaterThan(this)}
println(result)
}

fun greaterThan(x: Int): Boolean {
return x > 5
}

  In this case, run() will place a value of null in result because myInt is null. However, if myInt hadn't been null, result would contain the Boolean comparison provided by greaterThan().

• let(): This is a syntactical variation of run(), except that you can use it with a series of normal functions rather than function types with receivers. A difference between run() and let() is in the passing of values. You'd need to change the call in the previous example from this (an object) to it (a value), like this:

  val result = myInt?.let {greaterThan(it)}

• with(): Performs one or more operations on a non-null variable. To modify the previous example to use with(), you need to make myInt non-null, like this:

  val myInt: Int = 5
val result = with(myInt) {greaterThan(this)}

• apply(): Applies extension functions when provided with a non-null value. If the value is null, the output is null as well. This form uses the object this to pass values to the functions.
• also(): Applies normal functions when provided with a non-null value. If the value is null, the output is null as well. This form uses the object it to pass values to the functions.
• takeIf(): Performs a conditional comparison and, if the comparison is true, passes value to a lambda expression. Here's an example:

  val myInt: Int = 5
val result = myInt.takeIf {it > 4} ?.let {it * it}
println(result)

  In this case, the code determines whether myInt is greater than 4. If so, the code returns the square of the value in myInt. The variable being compared can't be null. When the comparison fails, the output is a null value.

• takeUnless(): Performs the opposite of takeIf(). The result is non-null when the comparison fails.