Runar Bjarnason

The nonstrict solution in chapter 5 improves on this answer. To quote exercise 3.24:

You may have some difficulty finding a concise purely functional implementation that is also effi- cient. That’s okay. Implement the function however comes most naturally. We’ll return to this implementation in chapter 5 and hopefully improve on it.

Rúnar

Yes, I think you are wrong about that. Scala is a general-purpose programming language. And if you stick with FP, then building a "huge" system is exactly the same as building a small system. The approach scales very well.

It's my experience that FP actually reduces the "complexity curve". The space of potential solutions to a given problem is enormous, and FP really puts constraints on the solutions that are allowed. This simplifies your search through the solution space.

I also find that when developing functionally you do not need huge teams. A small team of programmers well versed in FP can be extraordinarily productive. You will do more with less code. That code is harder to write, to be sure, but it is easier to maintain, extend, and test.

Scala is basically an object language just like Java. Its functional features, like lambdas, patterns, and type class dictionaries, are implemented as first-class objects with methods.

Joe Harry, that is another historical limitation of the JVM. Until Java 7 there was no way to get an unboxed method handle in the compiler, so in order to get first-class functions Scala and others resorted to anonymous classes with a single method (Function1 and friends). This definitely has a memory overhead.

Note that Scala methods are still just ordinary methods. This limitation is specific to first-class functions, or closures.

As of Java 7, the JVM provides method handles first-class in the byte code. So hopefully Scala will take advantage of these at some point.

does scala have any performance improvement compared to Java?

No. Scala code is exactly as fast or slow as the equivalent Java code.

if the underling JVM changes how will scala survive?

If the JVM changes, I suspect Scala will change too.

is there any limitations on scala since it is build on top of JVM ?

There are some limitations that come with the JVM, yes. For instance, there is no JVM byte code for tail calls. Tail call elimination is particularly important in FP, so we have to resort to techniques like trampolining (covered in chapter 13 of the book).

So you are saying that code written in Scala will be easier to maintain and make the developers happier?

Not exactly. I'm saying that adhering to the principles of functional programming will give you those benefits. The choice of language is not the most important in this regard. You can reap the benefits in Scala, Java, or C++, although it will be considerably easier in Scala than in the latter two, and easier still in languages like ML or Haskell.

Phelipe Maia:

In the book we try to give concrete examples of the benefits of functional programming. In short, those benefits are modularity and compositionality.

Modularity is the extent to which the parts of your programs can be separated and recombined in new ways. One practical benefit of this is code reuse. If it's easy to separate a part of your program out and reuse it in a different context, that enhances your productivity. Paul likes to say that "if you just eliminate all the duplicate code in your programs, you end up with functional programming". Another benefit of this is parallelization. If parts of your program can be cleanly separated, then those separate parts can be safely run in parallel. Testability is another. Again if you can isolate parts of your program, then they can be individually tested, which gives you confidence in the quality of your overall program.

Compositionality is the extent to which your program is composed of parts, each individually understandable, with clear rules of combining them. A compositional program can be understood just by looking at its parts and the rules of combination. Pure functions have this property because they are black boxes, and you can build larger black boxes just by plugging the output of one function into the input of another. The practical benefit here is that large systems can be assembled out of simple components.

A third and often overlooked benefit of FP is that it promotes programmer happiness. It is too easy to "create monsters", like you say, with other methodologies. Code that is hard to maintain makes your life as a programmer miserable. The accumulating technical debt creates friction, and makes it feel like you are trudging through a swamp whenever you need to change anything in the code. FP counteracts this. Code that is modular and compositional feels clean and is pleasant to work with, because it promotes clear separation of concerns (modularity), and safe recombination (compositionality). I have been programming for 28 years now, and I know how easy it is to create an unmaintainable mess with methodologies like OO. I think that if I hadn't come across FP, I would have stopped programming 10 years ago.

The patterns covered in part 3 are not "design patterns" in the traditional sense. They are really interfaces (that obey some rules) that come with libraries of very useful functions. On the question of whether part 3 contains examples of using these patterns in actual programming, the answer is that parts 1 and 2 contain those examples already. The purpose of part 3 is then simply to tie all the examples together and to think about them at a higher level.

chris webster:

In the book, we try to provide that practical guidance on FP that is missing from most books on Scala and from online courses and tutorials. We take you all the way from basic familiarity with FP concepts, through building a suite of practical libraries (for e.g. parallel execution, unit testing, and text parsing), all the way to advanced topics like streaming I/O. In the beginning we don't expect any prior knowledge of FP, but when you're done with the book you should have enough to try your hand at writing a purely functional web server, for example.

We don't believe you need to know about monoids and monads to get started. We cover those topics starting in part 3 of the book (chapters 10-12). But before we get to that, part 1 will give you basic familiarity with FP, and part 2 will give you practice and confidence writing your own purely functional libraries. By the time you come to chapter 11 on monads, you will see that it's just giving a name to a pattern that you will have seen over and over throughout the chapters before it.

Joe Harry:

Functional Programming in Scala is different from other Scala books in that it's fundamentally about functional programming (FP) rather than being about Scala per se. There are lots of ways to write programs in Scala, but this book tries to get the reader immersed in the purely functional way of programming. We think that this incidentally streamlines the process of learning Scala as well, since Scala has many language features that are not really relevant to FP. Here's an excerpt from the preface:

This is not a book about Scala. This book is an introduction to functional programming (FP), a radical, principled approach to writing software. We use Scala as the vehicle to get there, but you can apply the lessons herein to programming in any language. As you work through this book, our goal will be for you to gain a firm grasp of functional programming concepts, and the ability to comfortably absorb new material on the subject, beyond what we cover here.

I can't answer your second question about how it compares to a "Head First" style, since I have never read a book in that style. But this book will definitely take you head first into functional programming. We hope you have fun with it!

The book doesn't explicitly mention or follow Scalaz in any way. This is because we want you to be able to pick up this book 20 years from now, possibly with an old (by that time) version of Scala, and still get the benefits of it. That said, since we are both contributors to the library, Scalaz and the book naturally inform each other. For example, scalaz-stream is heavily influenced by the ideas in chapter 15, and in turn a lot of edits to that chapter came out of practical experience with the scalaz-stream library.

Thanks for the warm welcome, great to be here.