I do understand his initial frustration. Saying that FP languages solve the Strategy Pattern (say) with functions is correct, but so reductionist as to be useless. It's like saying you solved a problem using objects, or saying you solved a problem using monads. Sure, you absolutely can, but which monad you use is actually really important. There are a lot of things that fall under "The Strategy Pattern", and 'how you use functions to implement those' is just as big (and interesting!) a question as 'how you use objects to implement them'.
The Strategy Pattern comprises a single interface with a single method. In other words, the Strategy is a function, so it's entirely appropriate to say the FP equivalent of the Strategy Pattern is "function". Objects and interfaces just obscure that simple essence.
See, that’s what I mean about being reductionist. Is your answer wrong? Eh, not entirely, it’s just useless. Plenty of uses for the Strategy Pattern require more than just a function, and even those that a function is sufficient, what the function returns, and when, and why, matters. Reducing it down to a single function offers no understanding, it just sidesteps the point.
