I spent a large amount of personal time becoming an intermediate Haskell developer from 2009-2015, culminating in landing a job doing exclusively functional programming for an analytics team in a large company.
My experience made me give up on Haskell & functional programming entirel, despite my feeling that the principles of functional programming are often “better” than object orientation and other paradigms.
The only language-specific thing that turned me off of Haskell in a significant way was that so many important concepts in Haskell are implemented via pragmas that extend the language and either enforce syntax restructions, enable totally new (and often esoteric) syntax, or change the meaning of existing syntax.
This is really painful and makes you generally avoid great mew features and artificially limit yourself to more basic designs because of the learning curve and how committed to one siloed set of patterns you can become.
It reminds me of Dennis’s coffee shop idea in 30 Rock:
Dennis: One word. Coffee. One problem. Where do you get it?
Liz: Anywhere, you get it anywhere.
Dennis: Wrong. You get it at my coffee vending machine.
in the basement at K-mart. You just go downstairs. You get the key from David. And boom, you plug-in the machine.
^^ that’s what it feels like reading Haskell tutorials when all you want to do is multiple dispatch or heterogeneously type some built-in container, simple things in so many languages.
This alone wasn’t what put me off though. The real problem is sociological.
Most companies hardwire a feedback loop between development teams and product or business managers that teaches developers they will be rewarded for their ability to unsafely hack things into a Jenga tower of system components for the sake of rapidly addressing ad hoc business questions even when, perhaps especially when, nobody has the slightest idea if answering the ad hoc business request is likely to be worth the additional instability the hacks will put into the Jenga tower.
This is very nearly philosophically at odds with the spirit of functional programming, from a first principles level, which means even if you eke out a platform capable of dealing with this in a functional paradigm, youknow for sure that the business willnot see your work as valuable, and safety guarantees, correctness proofs, automatic parallelization, etc., will often notbe rewarded, meanwhile just hacking stuff into some C++ or Python codebase that “just works” will be rewarded.
It’s not a satisfying phenomenon, but it convinced me that it’s not worth investing any more of my time into functional programming.