I'm very sorry OP didn't stay the course, and opted to write an angry post instead. > Every few months some newbie comes along to the Haskell reddit and asks w

I'm very sorry OP didn't stay the course, and opted to write an angry post instead. > Every few months some newbie comes along to the Haskell reddit and asks why is Haskell documentation so confusing, and the post get destroyed by people telling them to get good or just pointing at academic papers. The Haskell subreddit has a monthly 'Hask Anything', and is generally a friendly forum. I searched: https://www.reddit.com/r/haskell/search/?q=documentation%20&restrict_sr=1 https://www.reddit.com/r/haskell/search/?q=documentation%20&... and was unable to find any such behavior. In fact, people asking for documentation were generally helped: https://www.reddit.com/r/haskell/comments/eo7orr/where_to_find_documentation/ https://www.reddit.com/r/haskell/comments/eo7orr/where_to_fi... > “Haskell doesn’t suck, the development environment does” There are certainly people who would agree with this, however our language server is pretty complete nowadays, we have amazing static analysis tools, a variety of formatters, I can't think of any tooling I desperately miss. Then again, I'm an editor person, not an IDE person... > Write types and interfaces for the types and fill in the blanks. Sounds familiar? Because that’s we’ve been doing with Java and the like using UML Ouch. It's very rare to hear anyone complain about having a type system with strong guarantees. UML... Well I guess I'm not a fan of specifying your design outside of your source code... > Professional developers find themselves describing the system in such concrete ways using types that when the requirements change suddenly their precious castle is reduced to dust Hmm, so generally the better at Haskell you are, the more you express constraints in terms of Haskell constraints, rather than concrete types. It's a style called `Tagless Final`. I recommend taking a look. It gives you strong guarantees, without breaking any castles. > Somehow Haskellers think that they are more productive with Haskell when the reality in the real world is that only a few languages can proudly make that claim, such as Python and Lisp. These are languages battle tested in actual software products As other people have pointed out, there are companies that use all three of these. I think it's safe to assume OP didn't measure the productivity of any developers before writing this. > Abstractions with types is a bad type of abstraction because it ignores the basic fact that programs deal with data, and data has no types Have you heard of datatypes? > In most cases people are looking for schemas, not types Schemas describe the structure of data. Types describe the structure of data. > Types wrap data and treat it like a black box whereas schema describes the shape and content of data The former here is actually more of a slight on encapsulation, which is something you can do in Haskell, but is probably more a goto recommendation of OOP languages. It can be pretty useful to only expose the inferfaces you want, and hide the implementation. > most haskellers would agree that purescript is a better choice compared to GHCJS. No man is an island, and yet Haskellers generally convinced themselves that other languages need to learn from Haskell Are you saying Purescript didn't learn from Haskell? Have you seen PureScript? > Instead of explaining Monads like all other design patterns out there, they insist on using some obscure definition from category theory to explain it Pick a monad explanation that suits you. There are plenty of posts / tutorials online. Some people like burritos, some people like mathematics. I recommend looking at the type of (>>=), as in the end, that's the only operation a Monad adds (above Applicative)... > Look, when monads are used without the infix notation, the result is horrendous and it looks like yet another callback chain I think you mean when they're used without `do notation`. This point seems moot, seeing as we have do notation. Explicit binds can be readable, if you're going pointfree. > I tried it myself. Of course, there are very smart people who do understand Monads, but most people would just tell you to “get an intuition for it”, which to be honest is total BS You'll get there, I recommend leaving the do-notation behind, and writing some functions over Maybe, [], and Writer. Don't give up on the learning process, there's still time to write a `How I learned Haskell` blog post, or maybe you can write the umpteenth Monad tutorial :)