I don’t think that’s entirely true. A lot of the ideas talked about in this article and that most people have already become familiar with are not very abstract. If you tried to build a large application out of nothing but pure function application, of course your code would become complex. We need more frameworks or libraries to take some of these ideas and bring them together in a way that scales. Elm, Vue and React are examples of tech that are doing this and, I think, make functional programming extremely appealing.
Better tooling can help, but so can 'not' forcing everything to be side-effect free.
Honestly, I'm getting downvotes for this but probably from the same types who thought CQRS or micros-services should be taken to the extreme and ended up totally crashing and burning.
Why can't techies see an approach, appreciate where it can help, and apply it where its useful? Why does it seemingly have to always be an all-in-or-nothing proposition?
> Why does it seemingly have to always be an all-in-or-nothing proposition?
This is one of the reasons I love JavaScript so much, and one of the things that stood out to me in the article. JavaScript is extremely expressive and allows you to write code without worrying about following some specific paradigm, which always seemed to me to be one of its biggest strengths, not a weakness as the article seems to suggest.
