I wrote this book for anyone who is interested in functional programming or is looking to transition from an imperative style to a functional one. If you’ve been programming in an imperative or object-oriented style, my hope is that you’ll be able to pick up this book and start learning how to code in a functional one instead.

This book will teach you how to recognize patterns in an imperative style and then walk you through how to transition into a more functional one. We will approach this by looking at a fictional company called XXY and look at their legacy code. We’ll then refactor its legacy code from an imperative style into a functional one.

We’re going to use a few different languages throughout this book:

Because functional programming is so closely tied to mathematics, let’s go over some basic mathematical notation.

Functions in mathematics are represented with a name(parameters) = body style. The example in Equation 1 shows a very simple function. The name is f, the parameter list is x, the body is x + 1, and the return is the numeric result of x + 1.

Equation 1. A simple math function

if statements in math are represented by the array notation. We will have a list of operations in which one will be evaluated when the corresponding if statement is true. The simple example in Equation 2 shows a set of statements to be evaluated. The function abs(x) will return x * -1 if our x is less than 0; otherwise, it will return x.

Equation 2. A simple math if statement

We also use a summation, the sigma operator, in our notation. The example in Equation 3 shows a simple summation. The notation says to have a variable n starting at 0 (defined by the n=0 below the sigma) and continuing to x (as defined by the x above the sigma). Then, for each n we add it to our sum (defined by the body, n in our case, to the right of the sigma).

Equation 3. A simple math summation

There are quite a few paradigms, each with its own pros and cons. Imperative, functional, event-driven—all of these paradigms represent another way of programming. Most people are familiar with the imperative style because it is the most common style of programming. Languages such as Java and C languages are all imperative by design. Java incorporates object-oriented programming (OOP) into its language, but it still primarily uses an imperative paradigm.

One of the most common questions I’ve heard during my time in software is “why should I bother learning functional programming?” Because most of my new projects have been in languages like Scala, the easiest response I can give is “that is what the project is written in.” But let’s take a step back and actually answer the question in depth.

I’ve seen quite a bit of imperative code that requires cryptographers to fully understand what it does. Generally, with the imperative style, you can write code and make it up as you go. You can write classes upon classes without fully understanding what the implementation will be. This usually results in a very large, unsustainable code base filled with an overuse of classes and spaghetti code.

Functional programming, on the other hand, forces us to better understand our implementation before and while we’re coding. We can then use that to identify where abstractions should go and reduce the lines of code we have written to execute the same functionality.

When we think of OOP, we normally think of a paradigm that is in a class of its own. But if we look at how we write OOP, the OOP is really used for encapsulation of variables into objects. Our code is actually in the imperative style—that is, it is executed “top to bottom.” As we transition to functional programming, we’ll see many more instances in which we just pass function returns into other functions.

Some people see functional programming as a replacement for OOP, but in fact we’ll still use OOP so that we can continue using objects that can maintain methods. These methods, hoever, will usually call static versions that allow us to have purer and more testable functions. So, we’re not replacing OOP; rather, we’re using object-oriented design in a functional construct.

Concepts such as design patterns in Java are so integral to our daily programming that it’s almost impossible to imagine life without them. So it is very interesting that, by contrast, the functional style has been around for many years but remains in the background as a main programming paradigm.

Why, then, is functional programming becoming so much more important today if it’s been around so long? Well, think back to the dot-com era, a time when any web presence was better than none. And what about general applications? As long as the application worked, nobody cared about the language or paradigm in which it was written.

Requirements and expectations today are difficult, so being able to closely mirror mathematical functions allows engineers to design strong algorithms in advance and rely on developers to implement those algorithms within the time frame required. The closer we bind ourselves to a mathematical underpinning, the better understood our algorithms will be. Functional programming also allows us to apply mathematics on those functions. Using concepts such as derivatives, limits, and integrals on functions can be useful when we are trying to identify where functions might fail.

Large functions are not very testable and also not very readable. Often, as software developers, we find ourselves presented with large chunks of functionality thrown into one function. But, if we extract the inner workings of these large, cumbersome functions into multiple, smaller, more understandable functions, we allow for more code reuse as well as higher levels of testing.

Code reuse and higher levels of testing are two of the most important benefits of moving to a functional language. Being able to extract entire chunks of functionality from a function makes it possible for us to change the functionality later without using a copy-and-paste methodology.

The following typographical conventions are used in this book:

Supplemental material (code examples, exercises, etc.) is available for download at https://github.com/jbackfield/BecomingFunctional.

This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documentation. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing a CD-ROM of examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of example code from this book into your product’s documentation does require permission.

We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Becoming Functional by Joshua Backfield (O’Reilly). Copyright 2014 Joshua Backfield, 978-1-449-36817-3.”

If you feel your use of code examples falls outside fair use or the aforementioned permission, feel free to contact us at [email protected].

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.

Please address comments and questions concerning this book to the publisher:

We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at http://bit.ly/becoming-functional.

To comment or ask technical questions about this book, send email to [email protected].

For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.

Find us on Facebook: http://facebook.com/oreilly

Follow us on Twitter: http://twitter.com/oreillymedia

Watch us on YouTube: http://www.youtube.com/oreillymedia

I’d like to thank my wife, Teri, and my daughter, Alyssa, for putting up with me during the writing of this book. I’d also like to thank Kevin Schmidt for introducing me to Simon St.Laurent, who made this book a reality, and my bosses, Gary Herndon and Alan Honeycutt, for allowing me to push the boundaries at work and try new things. I’d especially like to thank Meghan Blanchette, who kept moving me along and made sure that I was continuing to make progress along the way. Finally, I want to thank my parents, Sue and Fred Backfield, for believing in me and pushing me to continue learning and growing when I was a kid. If it weren’t for all of you making a difference in my life, I wouldn’t be here sharing my knowledge with so many other aspiring developers today.

There are lots of other people I’ve met along the way who have helped me become a better developer; I know I’m going to leave people out (and I’m sorry if I do), but here is a good attempt at a list: Nick Angus, Johnny Calhoun, Jason Pinkey, Ryan Karetas, Isaac Henry, Jim Williams, Mike Wisener, Yatin Kanetkar, Sean McNealy, Christopher Heath, and Dave Slusher.