I have graciously received a copy of The Book of F# written by Dave Fancher from No Starch Press. It will be a great resource when teaching and using F# at Intelliplan, so in return I’m writing a review here. That said, I will be honest about my opinion.

The book of F# is a book for a beginner at functional programming, in a similar vein to Real World Functional Programming. This is my review of that book. With that as a background, here’s my review of The Book of F#.

The pacing in this book is better than most introductory books for me, most likelt because in the introduction Dave writes that his target audience is “experienced .NET devs looking to break into functional programming […]”.

Having used F# professionally now for a couple of years and similarly to Dave having worked with .Net since version 1.1, I think I’m a fairly close to the target audience.

What am I looking for in a book?

I’m looking for a story that inspires me enough to understand its teachings while keeping me engaged. For programming books I want something above the syntax; I want the author to have a firm grasp of the problems that he’s solving and solve them idiomatically in the topic language.

We are currently developing with F# as our main language in my team (with a lot of C# maintenance), deploying it on CentOS on mono, CI builds with TeamCity and orchestration/configuration with MCollective/puppet. Our dev rigs are OS X/Windows hybrids and we use a fair amount of virtualisation: VirtualBox/vagrant, Parallels and Amazon/EC2. As such we have some experience with F# on a non-Windows platform.

The style

This book discusses the basics of F# in a way that I recognise - a lot of the other open source code in F# is written in the same style advocated by the author; it’s a relevant style.

Chapter 1 through 3

The book doesn’t go outside the Windows platform however, and not outside the confines of how the language is used.

I don’t mind this, because it brings a focus to the writing. For newbie, however, it would be useful to have an introduction on how to use it outside Visual Studio, e.g. with fsharpi and how to compile it to use on a free platform.

In the second chapter we find the common ‘click here in Visual Studio, then next, then…’, a theme common amongst .Net devs. FSharp.ProjectScaffold could have been mentioned, as well as some guidance on how to find/use the project/targets-files - a point of contention when it comes to build on CI servers without Visual Studio, such as TeamCity.

The third chapter, Fundamentals, does what it says on the tin; goes through the fundamentals of the language. It’s well written and great for F# newbies.

Chapter 4 - Object Orientation

It’s an interesting choice to do in a book about functional programming, to spend 1/6 of the book discussing object orientation. The chapter is well written and I understand that the author is trying to create the bridge between knowledge from the C# OOP world the F# world. It’s a similar chapter to how object oriented Scala code is done.

By going through object orientation before patterns for functional programming, the book is making a sort of statement; it will be a map between two worlds, but it’s not interested in teaching functional programming per-se, just the syntax of the language.

In this chapter I would have loved a deeper dive into mapping object oriented patterns into functional ones. The author does state that pure functions make it easier to program, because there’s less state, which is true, of course.

Chapter 5 - Getting Functional

In this chapter I had hoped the sweet functional patterns were to be presented and explained; why should I do functional programming?

Instead the focus is on three things: function composition (currying, partial application, inline functions, recursion, tail calls), structual/syntactical F# (unions, pattern matching) and more syntax for types. Only two pages show a functional programming pattern: with an example on how to output a html document from a tree structure.

The content on those two pages is good; a recursive function traverses the tree and constructs a string. But why stop there? I wish the book had gone deeper, discussing the non-functional requirements that functional programmers come across.

In the example a string is built in memory. What would it take to extend the rendering of the string? Could currying be used to introduce dependency injection points allowing different structures to be built from the tree? What is there was a requirement to start sending data immediately? What about discussing side-effects and separation of them from the code (the author has a displayHtml function that has all the side-effects) - purification for example?

Why not use the recursive tree traversal to describe a core functional concept? The fold function?

Chapter 6 through 12

The rest of the book stays true to its course - introducing the syntax and features of F#. The chapters on units of measure (8) and quotations (9) were extra interesting for me; especially the one on quotations - because it’s so hard to find good writing and up-to-date documentation on it.

Chapter 10 on the query expression builder was extra well done, with ample examples, explained in a coherent and lucid manner together with notes on the pros and cons of each method. It’s fits with the author’s previous interest in LINQ - I will have immediate return of the time investment I did, reading this chaper, as we’re working with the query expression currently.

Unfortunately the quality of chapter 11 was dramatically lower, only rehashing what’s already available in the most basic examples online and without much care for making it idiomatic F#. Neither was there any mention of e.g. FSharp.Actor or the new kid on the block Akka.Net which are the natural progression from MailboxProcessor.


The Book of F# by Dave Fancher is a 4/5 star book for newbies to F# who have been programming C# before seeing the light. I wish there was a more holistic take on the concepts - just introducing some ideas from the functional world - zippers, lenses, homomorphisms, list-based functions, laziness versus strict languages, patterns for communication between concurrent processes, picklers, applicatives, functors and so on - would have made it a 5/5 book that could have stuck around for longer.

It’s current incarnation, however, is a great book for introducing a new, better, language to programmers of existing OOP languages. It introduces it gently and with an eye for the common “counter arguments” that are normally thrown up as arguments against functional programming.

I recommend buying this book if you want to get a better grasp of F#, the language, or if you are working with teaching object oriented programmers to be more functional. Because the book address these issues in well written, lucid writing, I expect it to have a large audience.

Twitter @henrikfeldt

Twitter @logarylib

Henrik Feldt +46 737 53 27 18 haf