Review: “Functional Programming in Scala” by Paul Chiusana and Rúnar Bjarnason

I started learning Scala programming language back in 2008. My professional background was in Java but I had some exposure to functional programming in the university. In order to better understand Scala and the functional programming concepts, I started reading the Scala white papers and ended up learning Haskell to understand the foundational whitepapers and core ideas. I was delighted when Paul and Rúnar published the book and I wished that it was available when we started building software at Jetlore. This book makes a functional design in Scala more approachable.

Summary

The main thesis of the book is that it is practical and beneficial to construct programs using only pure function — the functions without side effects. Pure function is the function that is fully defined by its inputs and always produces the same output without any visible side effects to the rest of the program.

The authors introduce two important concepts to reason about functions: referential transparency and substitution model.

“An expression e is referentially transparent if, for all programs p, all occurrences of e in p can be replaced by the result of evaluating e without affecting the meaning of p. A function f is pure if the expression f(x) is referentially transparent for all referentially transparent x.”

Referential transparency allows us to use the substitution model that helps with reasoning about the code. You can always substitute the function call with the output value without affecting the program. This is how we usually solve the math equations by substituting the complex expressions with their results and simplifying the equation. At the same time, it helps with local reasoning when you look at the code block because you don’t need to keep the state changes in your head.

Another interesting aspect of the pure functions is that you can follow the types to deduce a possible implementation. For example, you have a function that takes a list of objects of type A and returns an integer: List[A] => Int. If the function is pure, then the most obvious choice for the implementation is the length of the list. You can also come up with an implementation that returns the index of the element in the list based on some criteria but that might be less practical given that you don’t have any other information about type A. However if that function can do side effects then there is no way to reason about it with good confidence without looking into the code.

One might wonder how anyone can write a useful program that doesn’t do any side effects — IO, mutation of the state, etc. The idea is to define the core of your program with pure functions and push out all the effects outside in the thin layer. The book provides excellent examples of how to achieve that and explains topics such as a functional design in general, common structures in functional programming, handling effects and IO. It gives a strong theme of separation of concerns where you separate the description of a computation from the interpreter that runs it. The authors propose to think of API as an algebra when working on the functional design. You define your domain as one or more sets of objects together with a collection of functions operating on them and a set of laws to restrict the definition of the functions and how they can be implemented. The book provides a lot of exercises that facilitate learning.

My experience

At Jetlore, we had a few experiences with functional programming design and used Scalaz library to facilitate it. Unfortunately, they were not very successful. The learning curve was too high and we didn’t spend enough time to prepare the training materials to facilitate the onboarding process of the new employees. As a result, it was evident that we would not be able to iterate fast enough as a startup and ended up using the hybrid approach — object-oriented design with functional flavor. That appeared as the most pragmatic way to build the software in our company. There was a good idea to refactor our ranking service by separating the definition of ranking from the way to run it using the concepts described in the book but we didn’t have enough time and resources to carry it out right before the acquisition.

Verdict

Highly recommended for software engineers interested in functional programming.