Paul Chiusano

Ari King wrote:
Most of the threads here discuss how/when FP is a better implementation choice than OO. Are there any circumstance where the opposite holds?

Like I was saying in another thread (https://coderanch.com/t/629025/Scala/Scala#2879406), we don't usually consider OO and FP to be in conflict. It's more FP vs imperative programming / using side effects. I don't think using side effects are ever 'better', though we might use local mutation within the implementation of a pure function, say for performance. IMO, side effects are pretty universally bad when they are anything other than an implementation detail for a purely functional API.

The one thing I would say is that following FP is a discipline. After a while, following that discipline becomes effortless, but until you've learned enough FP, it is 'easier' to just resort to using side effects. That is, FP requires some up front investment - much of part 1 of our book is relearning how to do things that people already know how to do in imperative programming. There is some new stuff in part 1, but most of it is laying a foundation so that we can do all the fun stuff which is truly new and unique to FP in parts 2, 3, and 4.

Hi Ari,

You might want to check out this old blog post of mine, which is sort of an experience report I wrote after our first year or two using Scala: http://pchiusano.blogspot.com/2009/08/scala-success-story-commercial-usage-of.html Some of the stuff in there is out of date, and I may not agree with everything in there anymore, but it talks about some of the benefits we got from using Scala. Overall, I'd say the benefits we got from using Scala were just the usual benefits one gets from FP - compositionality, reuse, modularity, testability, much fewer bugs, etc. Personally, I did not know much FP when I started using Scala (I had used functions like map/filter/fold in various languages, and that was about it), and found that the more I learned, the more I saw of the above benefits.

As for why not Clojure or Groovy, well, I feel that a good static type system is essential to functional programming. Also, Clojure I don't think was even out when I started using Scala (late 2007) at Capital IQ, or if it was it was super super new. I do remember looking at another JVM language, CAL (http://openquark.org/Welcome.html), but I felt like Scala had more momentum and more seamless interoperability with Java, which was important.

Sure. To start, here's what we say in the preface about the overall structure of the book: (FYI, there is an older version of the preface available here: http://manning.com/bjarnason/FPiS_meap_ch01.pdf, that should be updated soon.)

The book is organized into four parts. In part 1, we proceed from a startling premise--that we restrict ourselves to constructing programs using only _pure_ functions with no _side effects_ such as reading from files or mutating memory. In the first chapter of part 1 we will explain exactly what that means, and give you some idea of the benefits you might reap from that. This idea, of programming with pure functions, leads to a very different way of writing programs than you may be used to. We therefore start from the very beginning, relearning how to write the simplest of programs in a functional way. The chapters in part 1 give an overview of fundamental techniques like how to organize small functional programs, define purely functional data structures, handle errors, and deal with state.

Building on this foundation, part 2 is a series of tutorials on _functional design_. We work through some examples of practical functional libraries, laying bare the thought process that goes into designing them.

While working through the libraries in part 2, it will become clear to you that these libraries follow certain patterns and contain some duplication. This will highlight the need for new and higher abstractions for writing more generalized libraries, and we introduce those abstractions in part 3. These are very powerful tools for reasoning about your code. Once you master them, they hold the promise to make you extraordinarily productive as a programmer.

Part 4 then bridges the remainder of the gap towards writing real-world applications that perform I/O (like working with databases, files, or video displays), and make use of mutable state, all in a purely functional way.

Throughout the book, we rely heavily on programming exercises, carefully sequenced to help you internalize the material. To understand functional programming, it's not enough to learn the theory abstractly. You have to fire up your text editor and write some code. You have to take the theory that you have learned and make it a part of yourself, and of your work.

Going chapter by chapter, here's a bit more detail on part 1:

* Chapter 1 defines FP to mean the absence of side effects, more technically in terms of referential transparency, and shows some of the benefits using a worked example.
* Chapter 2 introduces Scala syntax, and the idea of first-class and higher-order functions.
* Chapter 3 introduces how to define purely functional data structures, using the immutable, singly-linked list as a worked example. We use this opportunity to introduce Scala syntax for what are called algebraic data types, and patterns matching.
* Chapter 4 covers how to do error handling without exceptions. Throwing and catching exceptions is not purely functional.
* Chapter 5 covers laziness, and how it can be used to improve the efficiency and modularity of functional programs.
* Chapter 6 talks about how to handle state in a purely functional way, without actually requiring side effects.

After part 1, we now have the 'vocabulary' needed to start writing functional libraries. Part 2 walks through libraries for defining parallel computations (chapter 7), property-based testing (chapter 8), and parsing (chapter 9). The part 2 chapters have a very different feel than the rest of the book - they are less linear, as we are trying to show the playful, iterative, and creative nature of functional design, and give some insight into how it can proceed. There are lots of exercises, some more open-ended, to try to get readers to try their hand at functional design using the tools developed over the course of part 1. We also introduce lots of related ideas as they come up.

We notice in part 2 that while the domains of these libraries are all very different, very similar structures emerge in the design of each library. Part 3 is devoted to exploring these common structures. By this point in the book, we expect readers will see the need to get rid of the duplication we've seen in writing various functional libraries in parts 1 and 2. We cover a few common structures, monoids (chapter 10), monads (chapter 11), and applicative functors (chapter 12), which eliminate duplication seen in parts 1 and 2, and also try to give some idea of how to spot these more abstract structures in day to day programming.

Finally, in part 4, we turn our attention to interacting with the real world, building on the material in parts 1-3. Chapters 13 builds up to an IO type supporting nonblocking I/O, introduces some related ideas (the 'free' monad), and shows how to 'embed' imperative programs into functional programs, giving us first-class imperative programs that can be combined and abstracted using the usual tools of FP. Chapter 14 is a bit more philosophical - it explores more carefully what it means to be free of side effects, discusses 'observability' of side effects, and introduces the idea that _local_ effects do not break functional purity / referential transparency. It also demonstrates how we can restrict the scope of the side effect of mutation using the type system.

Finally, chapter 15 builds up a more compositional library for doing IO, which lets us more cleanly separate the logic of our program from the I/O.

Our goal is that by the end, you'll have all the tools you need to start writing pure functional programs, for just about any programming task you can think of. This is not to say that you'll know everything there is to know about FP, but we expect you'll have all the tools and background to quickly learn whatever comes up in your day to day work with FP.

Hope this helps.

Even though Scala is a multiparadigm language, it works well for purely functional programming, and writing the book with Scala would lets us reach a different, wider audience than if we wrote the book using a language like Haskell. Scala has a nice adoption story precisely because it is multiparadigm, interoperates with Java, and does not impose any particular programming style - people can start out using Scala as if it were Java with different syntax, and gradually incorporate more FP into their work. Runar and I also really felt like there was an unfilled niche, in that there were various books about Scala, but not really any books that deeply explored using Scala as a purely functional language, which was how we were using it.

Personally, I use Scala as a purely functional language in my day to day work. We usually refer to functional programming in contrast to imperative programming, not in contrast to OOP. People mean lots of different things by OO, but to the extent that it is well-defined, I think it relates more to how one organizes code, rather than whether side effects are used.

Not really, we just didn't like the default Manning style all that much and asked if they could do just a simpler, more modern style cover.

I think Java 8 adding anonymous functions is a good thing. It makes it that much easier to do FP from Java, and as a consequence we'll hopefully see more JVM support for optimizing this style of programming. Scala will still be a nicer functional language than Java due to other features like pattern matching, its more powerful type system, and implicit arguments (technically Scala's implicits feature is a bit more powerful than necessary, but something like this is very useful for FP). I don't see Java adding these features anytime soon, or ever.

Also, we are more interested in FP in general, rather than Scala the language in particular. If people start doing pure FP in other languages, I think that's great!

HI Anujit, the book is definitely about using Scala as the vehicle for purely functional programming. In many ways, the book is not 'about' Scala, we are just using Scala as the vehicle for teaching FP, though you will certainly learn Scala as a consequence of working through the book. That said, though our main goal is teaching FP, when we introduce new concepts / techniques, etc, where it makes sense we try to motivate and relate these things for someone coming from a more traditional OO background. Many of the part 1 chapters are 'relearning' the functional way of doing something that people already know how to do in imperative programming, and we definitely try to make the connection that although FP is different, it is not totally disconnected from what you already know. Parts 2-4 get into territory where there isn't as much of an analogue to other types of programming - much of that will be specific to FP and very new to people.

You can check out the preface (free online, along with chapter 1) here: http://manning.com/bjarnason/FPiS_meap_ch01.pdf It talks about what the goals of the book are, who the audience is, and how it is organized.

Hi Michael,

I would not say the book is targeted at Haskell programmers, we are definitely trying to make the work for someone coming from a Java background, without much or any prior exposure to functional programming. Here's what we say in the Preface regarding the audience:

This book is intended for readers with at least a little bit of programming experience. We had a particular kind of reader in mind while writing the book--an intermediate-level Java or C programmer who is curious about functional programming. But we believe this book is well suited for programmers coming from any language, at any level of experience.

Prior expertise is not so important as motivation and curiosity. Functional programming is a lot of fun, but it's a challenging topic. It may even be especially challenging for the most experienced programmers, because it can be such a different way of thinking than they might be used to. No matter how long you have been programming, you must come prepared to be a beginner once again.

This book does not require any prior experience with Scala, but we won't spend a lot of time and space discussing Scala's syntax and language features. Instead we will introduce them as we go, with a minimum of ceremony, mostly as a consequence of covering other material. These minimal introductions to Scala should be enough to get you started with the exercises. If you have further questions about the Scala language, you should supplement your reading with another book on Scala[1] or look up specific questions in the Scala language specification.[2]

[1]: http://www.scala-lang.org/documentation/books.html
[2]: http://www.scala-lang.org/files/archive/nightly/pdfs/ScalaReference.pdf

Part 1 of the book is just us explaining what FP is, and then walking through the basic techniques of FP. We try to motivate each technique for people who might be coming from an imperative programming background.

Hope this answer helps!

Happy to be here. Please ask us any questions you'd like about the book and/or Scala, and we'll do our best to answer.