Haskell as a language is excellent for these tasks and when you are familiar with it, you can be even more rapidly productive than with Python, and much, much more than with R.
The problem for me has not so much been any technical aspect of Haskell nor any technical benefits of Python or R. Instead, it has been sociological issues with the Haskell community.
I won't go into it too much, but the biggest one is that there is no cohesive way to understand what kind of progression of Haskell knowledge makes you "a beginner" or "intermediate" or "advanced" -- especially for the purposes of getting a job. You might have mastered all the basics from LYAH, and know monads inside and out, and then someone comes along and says you're totally a Haskell noob because you haven't used Template Haskell for 6 years, or you don't do everything with Monad transformers, or you don't have the API of some tool like Parsec committed to memory, or you don't use language extensions and LiquidHaskell to use the compiler as a proof system of the correctness of your code. In Haskell, you're always made to feel like you're constantly a fuck-up for not knowing the next great wrinkle of abstraction or the next great toolkit up the food chain.
No joke, I've experienced being called a Haskell "beginner" because I was not deeply familiar with LiquidHaskell. That's not a common opinion, but it gives you a sense of the variety. This stresses me out so much that I don't even bother applying to Haskell jobs anymore. I don't want to get an initial phone screen and then just be made to feel like I'm a dunce because I don't know how some category theory principle is embodied by phantom types or something. Yuck.
Getting Haskell jobs that will actually pay you according to your experience and ability to learn is very hard. Most places just don't want to hire people who aren't super experienced in Haskell, and they default to believing everyone is a beginner unless they wrote a math Ph.D. thesis on multiparameter type classes.
On the off chance that someone will talk to you, and they think "OK, this person has a bunch of years of data analysis in Python or R under their belt, and they know enough about Haskell to work pretty quickly with Monads and basic type classes ..." that means you are a junior engineer at best, and will be paid like it, even if your data analysis skill is very high or you're a very fast learner or you have an advanced degree or many years of experience.
I've never been able to figure out the impenetrable bubble around Haskell jobs, but this kind of culture of believing that about 99% of Haskellers are beginners and less than 1% are anything beyond a beginner is the biggest reason why I mostly gave up learning Haskell or searching for Haskell jobs.
It's funny because a lot of people argue functional programming is too much about elegance to be pragmatic, and they can "just get stuff done" with other tools. Then lots of functional programmer enthusiasts jump in and refute that (I believe correctly) but then turn around and only hire people if they jump through all of the unpragmatic too-much-elegance hoops. It's really vexing.
The problem for me has not so much been any technical aspect of Haskell nor any technical benefits of Python or R. Instead, it has been sociological issues with the Haskell community.
I won't go into it too much, but the biggest one is that there is no cohesive way to understand what kind of progression of Haskell knowledge makes you "a beginner" or "intermediate" or "advanced" -- especially for the purposes of getting a job. You might have mastered all the basics from LYAH, and know monads inside and out, and then someone comes along and says you're totally a Haskell noob because you haven't used Template Haskell for 6 years, or you don't do everything with Monad transformers, or you don't have the API of some tool like Parsec committed to memory, or you don't use language extensions and LiquidHaskell to use the compiler as a proof system of the correctness of your code. In Haskell, you're always made to feel like you're constantly a fuck-up for not knowing the next great wrinkle of abstraction or the next great toolkit up the food chain.
No joke, I've experienced being called a Haskell "beginner" because I was not deeply familiar with LiquidHaskell. That's not a common opinion, but it gives you a sense of the variety. This stresses me out so much that I don't even bother applying to Haskell jobs anymore. I don't want to get an initial phone screen and then just be made to feel like I'm a dunce because I don't know how some category theory principle is embodied by phantom types or something. Yuck.
Getting Haskell jobs that will actually pay you according to your experience and ability to learn is very hard. Most places just don't want to hire people who aren't super experienced in Haskell, and they default to believing everyone is a beginner unless they wrote a math Ph.D. thesis on multiparameter type classes.
On the off chance that someone will talk to you, and they think "OK, this person has a bunch of years of data analysis in Python or R under their belt, and they know enough about Haskell to work pretty quickly with Monads and basic type classes ..." that means you are a junior engineer at best, and will be paid like it, even if your data analysis skill is very high or you're a very fast learner or you have an advanced degree or many years of experience.
I've never been able to figure out the impenetrable bubble around Haskell jobs, but this kind of culture of believing that about 99% of Haskellers are beginners and less than 1% are anything beyond a beginner is the biggest reason why I mostly gave up learning Haskell or searching for Haskell jobs.
It's funny because a lot of people argue functional programming is too much about elegance to be pragmatic, and they can "just get stuff done" with other tools. Then lots of functional programmer enthusiasts jump in and refute that (I believe correctly) but then turn around and only hire people if they jump through all of the unpragmatic too-much-elegance hoops. It's really vexing.