How does one "over-engineer" a functional environment? By breaking functions down into even smaller pieces? By minimizing side-effects even further than before? These are all good things to do no matter what.
My one and only issue that I have with the "design"-side of FP is that it can be tough to organize multiple functions in an intuitive way. (The "soup of functions" effect, essentially).
It makes coming on to a new codebase tedious to trace, but I'd still rather than dealing with spaghetti OOP.
You can over-engineer point free style to create an uncomprehensible code base. Point free style with more than 1 unapplied parameter is basically a nightmare.
> How does one "over-engineer" a functional environment? By breaking functions down into even smaller pieces? By minimizing side-effects even further than before? These are all good things to do no matter what.
Off hand, overly tight coupling of unrelated by superficially comparable functions. Of course one can also do this in OOP environments as well. This is related to "God Functions" that are meant to handle way too much.
There's also those who fundamentally fail to understand what the point of FP is. The belief that it's just "my function isn't in a class."
Anything can be over-engineered, simply by violating Occam's Razor. Bad programs are filled with stuff operating on other stuff that is not essential. Programs in Lisp and Haskell do this as much as in any language, because few love simplicity.
My one and only issue that I have with the "design"-side of FP is that it can be tough to organize multiple functions in an intuitive way. (The "soup of functions" effect, essentially).
It makes coming on to a new codebase tedious to trace, but I'd still rather than dealing with spaghetti OOP.