That's a really magical analogy right there. Though I'd take it a step further and say nowadays even stumping for an FP language smacks of the same sort of thing.

Case in point: I've probably done more to evangelize functional programming by just demonstrating to colleagues that they too can write their own higher-order functions - just like LINQ! - in C# than an army of Haskellers could accomplish in a lifetime of hurling jargon from category theory. My thought is, if FP is really so great then I should be able to show people by writing some functional code and then having someone else come along later and go, "Hey, that's great!" When I find I can't do that then that's a signal that it's time to double-check the ingredients of my fruit-flavored beverage.

Yeah, that does mean I have to accept that Racket will forever be a hobby language for me. My boring sellout Herman Miller-cradled enterprise developer butt is comfortable with that.

> My thought is, if FP is really so great then I should be able to show people by writing some functional code and then having someone else come along later and go, "Hey, that's great!" When I find I can't do that then that's a signal that it's time to double-check the ingredients of my fruit-flavored beverage.

I don't know about that. Sometimes people must make the effort to move beyond their comfort zones in order to find tools that are (potentially) more useful. You cannot expect every improvement to be self-evident with minimal effort. There are significant rewards in "making the jump", so to speak.

I'd submit that if I can't find a spot where my favorite trick solves a problem in a way that I can easily demonstrate is better than the existing alternatives, then my favorite trick is a solution in search of a problem.

I agree with everything you say except for the "easily" part. Sometimes you have to make a cognitive effort; said effort is by definition harder than not making the effort. But the payoff may be worthwhile!

I don't subscribe to the notion that for something to be worthwhile, it must be readily apparent and "easy" to understand. Especially in the context of FP, where most programmers -- but this is changing, thankfully! -- are traditionally trained in imperative languages, which means for them learning the FP "purist" mindset implies a significant effort.

My grandmother (R.I.P.) could never learn how to use an ATM. For her, using one was daunting and too much of an effort. It terrified her that she might make a mistake and push the wrong button. Back when she was young, ATMs didn't exist and she didn't need them. Her solution in modern days was to ask a helpful relative to use the ATM for her. Does this mean these hellish machines are "a solution in search of a problem"?

> "FP communities: like debating which brand of natural spring water to give millions of thirsty people in the desert"

...who all claim that they're not thirsty and prefer beer :-)