Haskellのつらいところ
文字列型が多すぎ: LazyなByteStringしか受け付けないAPIにStringを渡すためにData.Text.LazyとData.Text.Lazy.Encodingをインポートし、packからのencodeUtf8...　https://twitter.com/fumieval/status/1180763933986045953/photo/1
ByteStringがStrict版もLazy版も同じ名前なため、Haddockではリンク先のURLを見ないと判別できない
整数から整数や実数などに変換する関数fromIntegralの名前が長すぎ
GHC拡張の入力が大変
モジュール名が長い上に、import qualifiedのタイプ数も多くてインポートが大変
リテラルにTypeApplicationできない (WONTFIX https://github.com/ghc-proposals/ghc-proposals/pull/129 )
インライン化やジェネリクス、型レベルプログラミングなどのテクニックを多用するとコンパイル時間が犠牲になる
ほとんどのライブラリでは、何をするにもアロケーションが必要である
レコード問題
型クラスによるオーバーロードは強力だが、 Data.Vector.toList と Data.Map.toList のように微妙に型クラス化できないケースだとオーバーロードを諦めざるを得ないし、メンバ関数という概念もないのでqualified importがどんどん増える
カスタム演算子は便利だが、名前衝突しやすい・qualifiedで使うと見た目が悪い・種類が増えてくると覚えづらい・(hoogleを使うという発想のない初心者には)ググラビリティが低い、と弱点も多く、多用を強いられるライブラリではストレス源にもなる
デファクトスタンダードのライブラリにはデザイン・パフォーマンス共によろしくないものが少なくない
ライブラリに対してアプリケーションが少ない
まともに例外を投げるには、データ型を定義してControl.Exceptionをインポートし、Exceptionのインスタンスを定義してからthrowIO…とテンポが悪いが、Preludeの純粋な関数は平気で実行時エラーを出す
Maybeで失敗を表現する悪習のせいで、Eitherを返す関数の名前がeitherParseやparseEitherのようにややこしくなる
#課題