↑の記事で（主題ではないと思うものの）Haskellの批判に結構な分量が割かれていて、その批判のなかに「ちょっと違うんじゃないかな」という点がいくつかあったので反論ぽいことを書きます。
"Haskell は真面目なアプリケーション開発には向いてない"について
これには多分いくつか事例を挙げればよくて、
- Facebook ではスパム等の攻撃と戦うためのシステムを Haskell で作っています。
Fighting spam with Haskell | Engineering Blog | Facebook Code | Facebook (この記事を書いている Simon Marlow 氏は Haskell および GHC の主要開発者)
- より「アプリケーション」な事例が必要なら、プレゼンツールの Prezi を挙げることができます。
- 日本での事例としては、ASAHIネットというプロバイダの認証サーバが Haskell で動いています。
-
もうひとつ日本での事例としては、Tsuru Capital という金融系の企業が（一部だけでなく）全面的に Haskell を利用しています。
このように Haskell は多方面の「真面目な」領域で用いられています。（特にプロバイダの認証サーバとか可用性への要求がやばそう）。
少なくとも "Haskell は真面目なアプリケーション開発に向いていない" とは言えないかなと思います。
～完～
各論への反論
これだけだとあれなので個別の批判点についても書きます。
ドキュメントがない？
Haskell の主要なライブラリホスティング場所である Hackage は、ライブラリをアップロードすると自動で Haddock という Javadoc 的な仕組みで API ドキュメントを生成して、ライブラリと一緒に公開します。その意味では Haskell のライブラリはほぼドキュメントが用意されているし、ドキュメントの形式にも統一感があって見やすいと言えます。
他の言語だとたまに２０行くらいの Usage でドキュメントを済ませるようなやつとか、API ドキュメントらしきものがあっても引数と戻り値の型が書かれていないやつとか、引数と戻り値の型は書いてあるけど全部 Object 型のやつがあったりしますが、それらに比べると Haskell は最低限のドキュメントとそのアクセス経路が保証されている点でリードしています。
ただ事実としてドキュメントが十分に書かれていないライブラリがあることも確かです。しかし私の実感としては、ドキュメントが十分でないものの多くは未成熟なものや実験的なもののようです。基本的に Haskell のメジャーなライブラリは自動生成の API ドキュメントだけで済ませているということはあまりないと思います。
これは Haskell に限らないことですが、ライブラリのドキュメントが十分でないというのはライブラリが未成熟なサインのひとつです。実用する予定なら未成熟なライブラリをそもそも選ばないようにすべきでしょう。
（まあごく稀に有名なライブラリでもドキュメントが整っていないのがあったりはします。ekmettさんはもう少しlens以外のライブラリのドキュメントも書いてほしい）
あと有名だからとか話題になっているからと言ってそのライブラリが production ready であるとか battle tested であることは意味しません。（これは私もよく間違えてしまうところです）。実用するライブラリを選ぶなら、新奇なものと主流のものは見分けましょう。これは何の言語でも必要なスキルだと思います。
言語とライブラリの進化が速すぎる？
おそらく2011～2013年くらいのことかなと思うのですが、この時期は確かにいろいろと新しいものが出てきました。当該記事で挙げられている Iteratee/Enumerator/Conduit というのはどれもストリーム処理ライブラリで、より良いやり方があるのではないかと盛んに議論されていました。（現在も模索を続けている人たちもいます）。
元記事で腑に落ちていない部分があって "Iteratee/Enumerator/Conduit などを何度も調査し直すことになって全然実装が進まなかった" という部分です。私の記憶によれば当時これらは乱立していて API も洗練されていなかったものの、どれもストリーム処理ライブラリとしての最低限の機能はすでに有していました。開発しているアプリケーションにストリーム処理ライブラリが必要と分かったなら、一度調査してどれかに決定すればいいだけのはずで、何度も調査し直したというのは決定のフェーズを先延ばしにし続けてしまったということなのではないかと思います。これは例えば React で作り始めたウェブアプリを Vue がいいと聞いて Vue で作り直したり Angular がいいと聞いてまた作り直したりという、似た技術が並立する状況でありがちな悪循環にはまってしまったのではないでしょうか。Haskell のライブラリの進化が速いというところには問題の原因はないと思います。
実際、今では Conduit が主流なものの「Iteratee を採用したプロジェクトをメンテしている」という話を私は2016年にも聞きました。おそらくどれを選んでも前に進めたのではないでしょうか。間違ったものを選んでしまうのではないかという不安はもっともですし私もよく分かります。しかし決定はどこかでしないといけないのです。"私はアプリケーションを作りたいだけなのに" と言うならなおさらです。
また元記事では "Yesod は新しいライブラリを大量に使うのでそれに引っ張られた" という趣旨のことも書かれていますが、これは Yesod の問題であって Haskell の問題とは言えません。
互換性壊しすぎ?
これは当時のことをあまりよく覚えておらず自信がないのですが Yesod はともかく Haskell (GHC) が互換性を壊すということがそんなに頻繁にあったでしょうか？ 自分にはあまりそんな記憶がないので、Yesod の問題が Haskell の問題と混同されているのではないかという気がしています。（ここはちょっと自信がないです）。
Yesod 以外でもライブラリが互換性を壊すということは当時は時折起こっていたことは覚えています。しかし元記事には Haskell と Yesod にしか言及がないのでその辺りのことは分かりません。
元記事の Yesod が自身のビルド方法を大転換したのについていけないと感じたという指摘は……やはり Haskell の問題ではなく Yesod の問題です。
そういえば最近、 別の言語のウェブフレームワークでビルド方法がdeprecatedになった という話がありましたね。現行verが 2.5 で、2.4 まではドキュメントに書かれているビルド方法だったと記憶しているのですが混乱とかなかったのでしょうか。
全体的に
ここまで見てきたように、元記事は全体的に Yesod の問題であるところを Haskell の問題であるように肥大化して書かれています。Ruby on Rails の問題を Ruby の問題だと言っているようで、ちょっと誠実な態度ではないなと思います。
完全に推測ですが、元記事の筆者の方は、もともと Haskell に強い意欲のあった方なのだろうと思います。意欲があったからこそ Yesod という大規模なフレームワークを導入したり、ストリーム処理ライブラリについてのコミュニティの議論に耳を傾けたりしたのでしょう。そんな方がどこかの時点で可愛さ余って憎さ百倍となって Haskell を嫌いになってしまったということは、Haskell を今も好きでやっている者としては本当に悲しく思います。
しかしいくら Haskell が憎かったとしても、過剰なネガティブキャンペーンを張ることはやめてほしいのです。嘘の情報でせっかくの初学者の意欲を減退させてしまうようなことは、それこそ避けたいと思っています。
私がこういう風に言うのは、私が C++ に挫折して Haskell を始めた人間だからです。人間には向き不向きというのがあって、Haskell の水が合う人もいれば C++ が最高という人もいる。それだけのことではないでしょうか。
で、どうすれば真面目なアプリケーションを作れるの？
自分のユースケースに合致していてかつ成熟したライブラリを選定する方法や、依存関係地獄から自由になるための方法は、最近の Haskell では充実してきています。それらを少し紹介していこうと思います。ただしひとつ念を押しておきたいのは、ライブラリの選定とかビルド環境の構築というのはプログラマの責任範囲であるということです。わざわざ実験的ライブラリを選択して後で後悔することになってもプログラマの自己責任のうちです。これは Haskell に限らずそうです。
依存関係解決、ビルド環境
最近の Haskell には Stackage というサービスおよび Stack というツールがあります。Stackage というのは「依存関係問題を起こさないコンパイラ・ライブラリバージョンのセット」のようなもので、ここからライブラリを落としてくると「コンパイラ-ライブラリ間」および「ライブラリ-ライブラリ間」の依存関係で悩まされることはまずありません。Stackage は基本的に Stack から使います。Stack は Stackage や Cabal や GHC をひとまとめにしていい感じに実行してくれるツールで、stack コマンドを知っておけば ghc コマンドや cabal コマンドを意識しないで Haskell 開発ができます。
冒頭に挙げた Facebook, ASAHIネット, Tsuru Capital の Haskell 事例は Stackage 以前からあるものなので、Stackage が真面目な Haskell 開発に必須かと言われればそうではないのですが、我々としては Stackage を使ってカジュアルに楽をしてやっていけばいいのでないかと思います。
ライブラリの選定
いい感じにメジャーで成熟した Haskell ライブラリを選ぶための指標としては State of the Haskell ecosystem というのがあります。これは Haskell が応用される各分野における Haskell 環境の成熟度と、そこに関連する主要なライブラリ等をリストアップしたものです。ライブラリを選ぶときなどは参考にするとよいでしょう。
また手前味噌ですが、当ブログでも Haskellライブラリ所感2016 というのを書いています。恐縮ながら合わせてご参照下さい。
別の観点としては「(Hackageだけでなく)Stackageに上がっているライブラリは最近までメンテされていることが期待できる」という大雑把な指標もあります。
人間的サポート
もし本当にビジネスとして真面目に Haskell を採用するなら、Haskell のコンサルティング会社と契約するのもひとつの手だと思います。有名な会社としては FP Complete や Well-Typed があります。Well-Typed はヨーロッパの会社ですが日本にもクライアントがいると彼らのサイトに書いてあります。
ふつうはそこまで本格的なサポートを受けるのはハードルが高いと思います。そういう場合は 日本Haskelユーザーグループ にコンタクトを取るのが良いでしょう。個人であれば、開放されている Slack チームに参加して質問チャンネルで何か質問を投げると暇な Haskeller が答えてくれます。実際に業務で Haskell を利用している人も何人か参加しています。