Goals, Part 1: Soft Goals Of This Book
Going through the thought process of “Why do I want to write a book about Scala/FP?” led me to develop my goals for this book. They are:
To introduce functional programming in Scala in a simple, thorough way, as though you and I are having a conversation.
To present the solutions in a systematic way. I want to introduce the material in the order in which I think you’ll run into problems as you learn Scala/FP. In doing this, I break down complex code into smaller pieces so you can see how the larger solution is built from the smaller pieces.
To discuss the motivation and benefits of FP features. For me it wasn’t always clear why certain things in FP are better, so I’ll keep coming back to these two points.
Because it helps to see the big picture, I provide several small-but-complete Scala/FP example applications. Showing complete applications helps demonstrate how you can organize your FP applications, and work with issues like handling state, I/O, and user interfaces.
I hope to save you the time and effort of having to learn Haskell (or some other language) in order to learn FP.
I want to help you learn to “Think in FP.” (More on this shortly.)
In general, I want to help you start writing FP code without having to learn a lot of mathematics, background theory, and technical jargon like that shown in Figure [fig:fpTerminologyBarrier].
I refer to this as the “FP Terminology Barrier,” and I’ll discuss it more in an upcoming lesson.
While I generally avoid using technical jargon unless it’s necessary, I do discuss many of these terms in the appendices, and I also provide references to resources where you can dive deeper into FP theory.
When I took my first thermodynamics class in college, I learned the quote I shared at the beginning of this chapter:
For me, this means that sometimes the only way you can learn something is to work on it with your hands. Until that first thermodynamics class I never really had to do the thing — work all of the exercises — to learn the material, but in that class I found out the hard way that there are times when I really have to dig in and “do the thing to learn the thing.”
Another time when I had this same feeling was around the year 2009, when I started learning a content management system (CMS) named Drupal. During that time I came across the following image, where someone (whose name I can’t find) made the point that Drupal didn’t have a learning curve, but instead it had a learning cliff, which they depicted as shown in Figure [fig:drupalLearningCliff].
There are two things to say about Drupal’s learning cliff:
I found the diagram to be accurate.
Looking back on it, learning Drupal was one of the most beneficial things I’ve done for myself since that time. While getting started with Drupal was difficult, it ended up being a great investment of my time. The rewards were significant, and I have no regrets about spending the time it took to learn it. (If you’re reading this text on a website, the page you’re looking at was generated with Drupal.)
Just like FP, the problem with trying to learn Drupal is that when you get to a certain point (a) it feels like there are many things you need to learn simultaneously, and (b) it’s easy to take accidental detours on the learning path. As the image depicts, you either keep learning, or you fall off the cliff.
I hope that by breaking the Scala/FP learning process down into small, manageable pieces, this book can help you stay on the path, and make the Scala/FP learning curve more like other, normal learning curves.
If you’ve read the book, Einstein: His Life and Universe, by Walter Isaacson, you know that Albert Einstein had to essentially go back to school and learn a lot of math so he could turn the Theory of Special Relativity into the Theory of General Relativity.
He published the “Einstein field equations” (shown in Figure [fig:einsteinFieldEquations]) in 1915, and other than trying to describe his theories to an advanced mathematician who could understand what he was talking about, there’s no way that Einstein could have developed these equations without buckling down and taking the time to learn the necessary math. (Even one of the smartest people in the history of Earth had to work hard to learn something new.)
In this book I hope to change the way you think about programming problems. As at least one functional developer has said, when you “Think in FP,” you see an application as (a) data flowing into the application, (b) being transformed by a series of transformer functions, and (c) producing an output.
The first lessons in this book are aimed at helping you to “Think in FP” — to see your applications in this way, as a series of data flows and transformers.
As an example of this, when you get to the “FP is Like Writing Unix Pipelines” lesson, I’ll share diagrams like Figure [fig:howDataFlowsInUnixPipeline].
As this image shows, a Unix pipeline starts with a source of data — the who command — and then transforms that data with one or more functions. Data flows through the pipeline in only one direction, from one function to the next, and data is never modified, it’s only transformed from one format to another.
Another important part of “Thinking in FP” is that you’ll find that FP function signatures are very important — much more important than they are in OOP code. I cover this in depth in the lesson, “Pure Function Signatures Tell All.”
In summary, my goals for this book are:
To introduce functional programming in Scala in a simple, thorough way.
To present the solutions in a systematic way.
To discuss the motivation and benefits of FP features.
To share several small-but-complete Scala/FP applications to show you how they are organized.
To save you the time and effort of having to learn another programming language in order to understand Scala/FP.
In general, to help you “Think in FP.”
An important part of the learning process is having a “Question Everything” spirit, and I’ll cover that next.