Parse, don’t type-check
Reading articles like this makes me want to avoid Haskell.<p>It seems like the language is so over-complicated that it requires developers to invent an entire religion to be able to effectively apply it to real world use cases.<p>From the perspective of a non-Haskell coder who worked with many different mainstream languages, I find that many articles written about Haskell, Erlang and Elixir seem to have no meaning outside of their own narrow domain; they try to present some solutions as some universal insight which is applicable to all languages. In fact, they seem to revolve around solving problems which the language itself created and only exist in that language.<p>I like languages which stay out of my way and don't create any new problems or require inventing unnecessary abstractions and ideology (my OOP philosophy is so simple, I could explain it to a 10 year old). I can't believe that you would need several articles to explain to developers how to do something as trivial as validation. It's not rocket science (...well it shouldn't be). In the communities I participate in, most developers seem to intuitively know how to do validation... There are multiple ways to do it. You just have to think a bit to figure out which way is the best for your project.<p>A lot of these trendy languages seem to be on a futile mission to try to automate away some of the complexity of building software. Building software is irreducibly complex because there are always going to be a huge number of possibilities at every step; this is because the real world (which software tries to model) is complex, always more complex than it seems. That's why I like simple expressive languages which stay out of my way. Any tool which constrains my thinking into specific narrow patterns is going to make my work harder and more error-prone, not easier.