Hi Paul,
Does your book cover use cases where functional programming is a better approach ?
Sure, since functional programming is always a better approach
More seriously, this is highly subjective. It depends upon your own criteria. If you think about performance, the goal of functional programmers is often to do as well (or nearly as well) as the imperative version. However, some functional programs are faster than their imperative counterpart. But in general, functional programs are a bit slower.
If you think about the time needed to write a program, this is of course also subjective. An imperative programmer will have to struggle to think functionally. So, he will be less productive at first. For an experienced programmer, I would say that writing a somewhat complex functional program that compiles takes a bit longer that its imperative counterpart. The difference is that a program that compiles will have much less bugs. It will have "functional" bugs (nothing related with functional programming, but to programs with incorrect algorithms, for example) but it will rarely have implementation bugs. No unexpected null pointer (BTW, I don't really no what an expected null pointer is!), no concurrent access error, no index out of bound, no class cast exception and so on.
In the end, functional programmers are more productive.
There is another reason for this: functional programming is not only about programming using (pure) functions. It is also about pushing abstraction to the limit. In functional programming, there are no loops, no if then statements, no try catch and the like. All these structures are abstracted once for all, so the programmer can't mess with them. People often think that recursion is heavily used in functional programming. Although this is true, it is abstracted as well, so the programmer never have to use it explicitly.
So, after all, saying that functional programming is always a better approach may be a joke, but it is not far from being true!
Pierre-Yves