Late to the party again. The way I see it, when you face a programming problem you mentally divide it into subtasks and use solve each one in the most natural,

Late to the party again. The way I see it, when you face a programming problem you mentally divide it into subtasks and use solve each one in the most natural, sweet-spot manner learned from experience. Have to parse a minilanguage? Use an FP approach. Control UI widgets? Do it in OOP style, that's what it was designed for. Keep track of global game state? Just write it imperatively and be done with it. As a professional you need to understand the good ideas in your field, but as a responsible worker you need the wisdom to avoid pushing those good ideas beyond their proven area of application. One day you'll read an article somewhere that will demonstrate how Haskell is a great fit for ragdoll physics simulations (for example), like it happened before with Parsec for parsing (another example). Until that day... don't rush in blindly believing that purity is better for every class of problem. It might be, but we don't have anything resembling a proof yet. So learn from experience, and subdivide.