Chapter 1: functional example of buyCoffee actually has less logic than non-functional one

First of all, I’d like to thank the effort put into this book, I’m finding it very interesting. However, I find that chapter 1, where the benefits of FP are portrayed, is a bit misleading.

The example shows how the buyCoffee method is difficult to test and to reason with because it has a side effect (the credit card transaction). This is solved by changing the method to return both Coffee and Charge, without any actual communication or transaction. That is, the second version of buyCoffee is “incomplete” with respect to the first one, since more processing is needed elsewhere to achieve the same result.

The objective of the chapter is to demonstrate how FP leads to better code but, while it is true that the second version of buyCoffee is more readable and testable, one could argue that this benefit doesn’t come from FP, but from the fact that logic has been removed. I think a full example, i.e. one where an actual credit card transaction is recorded, is needed to do a proper comparison.

[runarorama]

It’s not really that the handling of the credit card payment doesn’t belong in a functional program, it’s just that it doesn’t belong hardcoded in this particular program. You have the right intuition in that the refactoring here is simply about separating concerns. But in the end that is all that FP is.

The situation is really quite similar before and after the refactoring. Nothing has been removed, since there is no real credit card handling code in the side-effecting program. There’s a call to a procedure that has a name that is certainly very suggestive, but in both cases, the “difficult part” is implemented somewhere else.

But before the refactoring, our program calls that other program as a hard-coded dependency. After the refactoring, our program returns a value, which the caller will pass to another program. We’ve just moved the problem around. We’ve “inverted control”, so to speak.

Since all we’re doing is organizing code differently, it’s totally reasonable to react with “what’s the big deal?” But separating concerns like this consistently has far-reaching consequences that we explore in the rest of the book. They are absolutely not obvious at first, and they can’t really be made obvious in a single toy example in the beginning.

[quiram]

Thanks for your reply. Personally, I don’t feel the issue is really addressed for two reasons:

1. The fact that there is a recorded presentation somewhere explaining something doesn’t mean the book is complete; for the chapter to be valuable it should be self-contained.
2. The intent of the chapter seems to be showing how functional programming makes for better code, however, when I read that code, my conclusion as a reader is “sure, the code is better, but that has nothing to do with FP, that has to do with the fact that you have removed logic; procedural code can also be made nicer and more readable if you remove the difficult parts and implement them somewhere else”.

If, in the end, the conclusion is that handling the actual state of the credit card payment is something that doesn’t belong in a functional program and has to be done somewhere else, then, as a newbie on the matter, I am left with a feeling that FP is not really enough and therefore not a serious option for the real world, which I’m sure is not the intent of the book.

Not trying to criticise, just trying to point out something that could prevent new practitioners from fully adopting FP.