IMO, there are a few things going on here:
1) iteration patterns. It’s much simpler, easier, and less bug prone to reason about programs that use map, reduce, and foreach to iterate over collections than it is to reason about programs iterating over collections with for loops. This makes it easier to test and maintain programs over time with minimal regressions
2) distributed computing, our general frameworks and performance reasoning has led us to a place where local state is generally not used in the types of places it used to be. Things (like query results etc) are cached in distributed data stores, not in heap memory. This leads to a more functional style.
3) people feel burned by the old school j2ee style enterprise object oriented programming and do not want to create or maintain “XXXfactorywhatever” classes or have deep preinstantiated object pools to do a simple thing. FP is a way to avoid those design patterns.
2) distributed computing, our general frameworks and performance reasoning has led us to a place where local state is generally not used in the types of places it used to be. Things (like query results etc) are cached in distributed data stores, not in heap memory. This leads to a more functional style.
3) people feel burned by the old school j2ee style enterprise object oriented programming and do not want to create or maintain “XXXfactorywhatever” classes or have deep preinstantiated object pools to do a simple thing. FP is a way to avoid those design patterns.