Functional Thinking: Paradigm Over Syntax

I was disappointed in this book. It is really about ways in which you can force Java to adopt functional mechanisms. But (as Ford himself has advocated) in a decentralized software environment, one shouldn't have to continue to use Java. I would have been more interested in the specifics of the functional pearls to learn, using Groovy or Closure or Scala (etc) as the example language, rather than a multi-page source code extravaganza showing how Java might use a 3rd party extension (support for which is unclear) to achieve the same results.

The best part is the latter chapters, when Ford begins to explain how common OO patterns (Strategy for example) can be more easily done functionally. However, throughout the book there is a complete lack of insight into exactly how implementing things functionally will improve X. We don't even get a sense for what X is - productivity? maintenance costs? speed? The analytic argument that abstracting state to the language will improve understanding is reasonable, but no evidence is presented to back this up.

Ultimately the question has to be whether adding functional thinking to your codebase is worth the cost - of reworking the code, of adding a second paradigm one needs to understand. Ford does not present much evidence of this. As far as I can tell most places that really benefit from functional programming already use it.

An overview, aimed squarely at Java programmers

I read the early release version, which contains some typos and is missing the finalized citations and images. And apparently missing some connective tissue as well, as the transitions between sections are a bit choppy.

Despite the book's length, it is essentially an overview, with the principles of functional programming condensed into a couple of chapters, giving examples of functional code and contrasting it with imperative or OO code.

I liked that the functional code examples were in a variety of languages, giving a glimpse of the variety available, and letting the reader translate into the language of his/her own choice. I disliked that
all of the imperative code examples were in Java, which seems to be an awkward choice for imperative code, being so strictly OO.

A large chunk of the book was given to showing how to get functional languages to do OO sorts of things, and OO languages, specifically Java, to do functional things. On one level this makes sense, as you would want to have the widest variety of tools available in whatever language you choose to use. But on another it makes me feel uneasy, as if you're trying to get around the fact that you didn't choose the right language for the task in the first place.

I would recommend this book for programmers who grew up with Java, and know nothing else, as it will expose them to different ways of doing things. But more experienced programmers would be less likely to learn much from it.