Haskell is one of those things that people either passionately love or hate.
Because of its uncompromising philosophy, programming in Haskell (or in any other purely functional programming language for that matter) has to pay an upfront cost of structuring side-effects. Type-driven development turns out to be a very useful approach to programming for those who have acquired a sufficient degree of proficiency in typed functional programming.
Granted, the world is messy and computational solutions will therefore have to deal with this messiness which often doesn't fit the neatness of purely functional programming right away. However, what I find interesting is that research into abstractions and ways to manage side-effects have led to insights and knowledge and into computing that couldn't have been readily obtained if the strait-jacket of pure functions was not put on. Such abstractions and connections with algebra of computations all help develop tools for building reliable software.
IMHO, the fact that Haskell is actually used in production is somewhat an accident. I think it began with people who programmed in Haskell for fun decided to try it out on solving real-world problems. And then gradually, when monad transformers came around, using Haskell in production became a real option.
I don't think the time commitment to learning Haskell is much more (if at all) than that to learn C++. In fact, after having programmed in C++ for quite a few years, I have pretty much given up on it. Obviously, if one needs to put food on the table, learning Haskell at the expense of other languages du jour would be a mistake. But being able to approach computing from the functional paradigm could be deeply rewarding.
Slippery slope arguments should not be regarded as logical arguments. They are predictions. Calling it a logical fallacy is a strawman argument because in reality, slippery slopes have been observed.
Until recently, learning Haskell for solving "real-world" problems is not at all easy. But there are now a lot more resources that one can consult.
I think it is highly rewarding to learn to program in Haskell. It offers you another perspective of approaching a computational problem and has a great ecosystem for many applications. And if you ever want to get into theorem-proving with Coq or Agda, knowing Haskell is a huge bonus.
My suggested learning path is as follows:
1. Read Get Programming with Haskell and do the Haskell MOOC at https://haskell.mooc.fi/ at the same time.
2. Read sections in Haskell Programming from First Principles not covered in 1.
3. Read Haskell in Depth.
Many years ago, I tried to learn Haskell from Haskell Programming from First Principles but couldn't get to the point I could write meaningful applications. I gave up after about a year. Early this year, I completed the Haskell MOOC and read most of Haskell in Depth and now I have a much better command of the language. And doing exercises on CodeWars, Hackerrank, and Exercism really help.
I would advise ignoring both the glowing praises and scathing criticisms. Learn it well enough and form your own judgement, assuming of course that you have time to do so.
Because of its uncompromising philosophy, programming in Haskell (or in any other purely functional programming language for that matter) has to pay an upfront cost of structuring side-effects. Type-driven development turns out to be a very useful approach to programming for those who have acquired a sufficient degree of proficiency in typed functional programming.
Granted, the world is messy and computational solutions will therefore have to deal with this messiness which often doesn't fit the neatness of purely functional programming right away. However, what I find interesting is that research into abstractions and ways to manage side-effects have led to insights and knowledge and into computing that couldn't have been readily obtained if the strait-jacket of pure functions was not put on. Such abstractions and connections with algebra of computations all help develop tools for building reliable software.
IMHO, the fact that Haskell is actually used in production is somewhat an accident. I think it began with people who programmed in Haskell for fun decided to try it out on solving real-world problems. And then gradually, when monad transformers came around, using Haskell in production became a real option.
I don't think the time commitment to learning Haskell is much more (if at all) than that to learn C++. In fact, after having programmed in C++ for quite a few years, I have pretty much given up on it. Obviously, if one needs to put food on the table, learning Haskell at the expense of other languages du jour would be a mistake. But being able to approach computing from the functional paradigm could be deeply rewarding.