> Is there also a risk with FP too that people fall a little too much in love with “elegant” code only to find out later that maybe simpler is better

I know some functional programmers who write complex code because they want to use the latest features of the type system. They get additional type safety, or better code factorization, but it results in code that is very hard to read and maintain, especially for people not as skilled as the initial programmer.

There's been a "simpler is better" conversation bouncing around the FP community as well lately.

Jumping on all the shiny-new-feature bandwagons that makes code drift towards unnecessary complexity, even if it technically makes things "better" given some sort of objective context, is something a team working with these languages really needs to consider.

The two that I can personally thing of are using higher order functions unnecessarily (i.e. sometimes it is better just to use a boolean flag rather than handing in a callback) and too much indirection (though honestly I see this more in languages like Java than functional languages).

I've outsmarted my future-self on several occasions. So yeah, there's a risk.

Generally in FP, “elegant” == simpler.

On that, I have seen lot of TypeFunctorMapMutatorKeywordsBeingImported to shorten the code and make it elegant...of course from the standard library or modules.

When you could have written it yourself with one or two extra lines. Why? Is it simpler? Or is it unnecessarily abstracted?

I mean, that’s on a case by case basis. I personally tend to do most of my FP in OCaml and F#, which have less of the tendency towards infinite abstraction that people sometimes accuse Haskell programmers of. I don’t think the approach you describe is elegant, but this is highly subjective.

1. It's code reuse. Don't rewrite code that's already written.

2. It's harder to understand. "Why didn't this use the standard library function? Is it doing something different? It doesn't look like it, am I missing something?"

It’s definitely not _always_ just about code reuse, particularly when you start really stacking GHC pragmas and such.