Learning FP takes real investment both in time spent learning and practicing the concepts and in time spent slowly misusing them in real projects until you deve

Learning FP takes real investment both in time spent learning and practicing the concepts and in time spent slowly misusing them in real projects until you develop your taste for where they're appropriate. This investment is regularly underestimated. Using FP introduces real advantage in terms of taste and simplicity, meaning that "advanced" concepts are not nearly as prevalent as someone who just learned them might hope. The rule of 3 is helpful and under-applied. Programmers new to FP get eager to use cool tech as opposed to leverage improved taste. FP can be utilized in many languages but in ones that don't guide your hand toward it—your Haskell, your OCaml, your Elm—it's easy to have it "mix" with other styles. It is not the case that combining FP and non-FP styles immediately make sense or work. It is the case that the strengths can be combined if done thoughtfully. All of these points generalize, though. As with any programming work, taste is important. It takes a while to develop and often needs to be developed within the context of a team. Tasteless FP is an awful, awful waste of time, energy, money. Someone who likes to throw all the jargon at your is a hobbyist, a proselytizer, or a fan. Not terrible, but not necessarily someone who can yet manage all of the necessary tradeoffs and balances. We take that sense of taste somewhat for granted in "mainstream" programming styles.