"spending hours giting gud at Haskell doesn't translate to hours saved solving real problems"
As long as we're playing "make baseless assertions at each other", my experience says otherwise. That's going to be hard for you to talk me out of.
Programmers still seem to have this bizarre belief that programming, uniquely among all the skills in the world, is not possible to improve via deliberative practice, and an equally bizarre belief that improved skills can't possible translate into better programs or even worse, must inevitably translate into worse programs. I can't wrap my mind around it.
I don't deny that there certainly is a trap where you learn these skills in a sort of greenhouse environment, then fail to translate them out of that environment properly. But that's the fault of the practitioner, not the skills, and I prove by demonstration that the skills can come out of the greenhouse and improve real code. I mostly write my professional code in Go, so you can be quite assured my production code is anything but a mess of functional paradigms inappropriately applied, since that's basically impossible in Go. I find what I learned in Haskell to be incredibly useful in Go.
I genuinely don't think you read the linked article. The author clearly is quite good at Haskell and hasn't fallen into this "trap" you're positing. It's not a failure of the "practitioner" at all. It's a fairly insightful point about the psychology of programming and the diminishing returns of the kind of skills we're talking about here.
> you can be quite assured my production code is anything but a mess of functional paradigms inappropriately applied
The point of the article was precisely that functional paradigms appropriately (which is to say, "appropriately") applied are themselves a design smell.
