This post highlights my biggest problem with the language: it's about the <i>how</i>, not about the <i>why</i>. For example, dependent types. They add significant complexity to the language and are intended to help with correctness. But are they an effective way to achieve it compared to alternatives? The fact that even current formal verification <i>research</i> is mostly looking elsewhere seems to suggest that the answer is likely negative, so why focus on them now? Or algebraic effects, about which the article says, "These effect-system libraries may help to achieve a boilerplate-free nirvana of tracking algebraic effects at much more granular levels." But is that even a worthwhile goal? Why is it nirvana to more easily do something that might not be worth doing at all?<p>Researchers who study some technique X ask themselves how best to use X to do Y, and publish a series of papers on the subject, but practitioners don't care about the answer to that question because they don't care about that question at all. They want to know how best to do Y, period. One could say that every language, once designed, is committed to some techniques that it tries to employ in full effect. But any product made for practical use should at least strive to begin with the <i>why</i> rather than the how, both in its original design and throughout its evolution. I work with designers of a popular programming language, and I see them spending literally years first trying to answer the why or the what before getting to the how. So either Haskell is a language intended as a research tool for those studying some particular techniques -- which is a <i>very</i> worthy goal but not one that helps me achieve mine -- or it's intended to provide entertainment for practitioners who are particularly drawn to its style. Either way, it's not a language that's designed to solve a problem for practitioners (and if it is, it doesn't seem that testing whether it actually does so successfully is a priority).<p>I think it's important to have languages for language research, but if that's what they are, don't try to present them as something else. And BTW, at ~0.06% of US market share -- less than Clojure, Elixir, Rust and Fortran, about the same as Erlang and Delphi, and slightly more than Lisp, F# and Elm -- and little or no growth (<a href="https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/" rel="nofollow">https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/</a>), I wouldn't call Haskell a "popular language," as this post does, just yet.