There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been im

There are certainly specialized areas where FP is inappropriate, maybe even for fundamental reasons (although I am not 100% sure of this: compilers have been improving rapidly, I don't have a great sense of how much further we can theoretically/fundamentally push a c compiler versus a haskell compiler, and the variety of possible type systems adds enough complications to make my head spin). But --and maybe there's a certain skew in my work experience?-- that's probably not really relevant to the vast majority of the programming that gets done. By my estimation, most professional software engineers spend most of their time working on nonrevolutionary, fairly mundane things, like basic crud apps, web apps, microservices, frontend, backend... While a minority (I think?) work on games, codecs, embedded systems, etc. (That's not to say that performance is never a concern in these areas, of course.) But dwarfing all of the above, in numbers, are all the people who are not professional software engineers, and who are writing code as an extension of the specific work they are doing in their domain (that's all your python scripts, R scripts, ad hoc sql, lab work, etc). I'll suggest something controversial here: anything people typically think python is good for, [haskell|racket|...] is probably way better at it. That's kind of where I see the most obvious use cases. In my view anyway, it's a pretty good bet that the step-change in complexity reduction you get with FP (big scary words notwithstanding; I am speaking here of the programs' complexity) would actually have a massive positive impact on the accessibility of programming/sw-engineering to newcomers, as well as on programming/sw-engineering's already-impressive propensity for enabling cross-talk between disciplines. There's soooooooo many low hanging fruits in programming literacy.