Haskellに欠点や問題はありますか？

次の（比較的些細な）個人プロジェクトのためにHaskellに飛び込むことを検討しています。Haskellに取り組んでいる理由は次のとおりです。

1. 純粋に機能的な言語に頭を悩ます
2. 速度。これは議論の余地があると確信していますが、私はHaskellがC ++に近い（そしてErlangよりもかなり高速であるように見える）ことをプロファイリングしています。
3. 速度。Warp Webサーバーは、他のほとんどすべてと比較して非常に高速です。

したがって、これを考えると、私が探しているのは、Haskellに付随する欠点または問題です。WebにはHaskellが良いものである理由に関する膨大な情報がありますが、そのい側面に関するトピックはあまり見当たりません（構文についての不満はまったく気にしません）。

私が探しているものの例は、PythonのGILのようなものです。CPython環境で並行性の使用を実際に検討し始めるまで、頭を悩ませなかった何か。

私が考えることができるいくつかの欠点：

• 言語の性質と学界に根ざしているため、コミュニティは非常に数学志向です。あなたが実用的な人であれば、これは時々圧倒される可能性があり、専門用語を話さないと、他の多くの言語よりも苦労するでしょう。
• 膨大な数のライブラリがありますが、ドキュメントは簡潔であることがよくあります。
• 入門レベルの穏やかなチュートリアルはほとんどなく、見つけるのが難しいため、最初の学習曲線は非常に急です。
• いくつかの言語機能は不必要に不器用です。顕著な例は、レコード構文が名前付けスコープを導入しない方法であるため、同じモジュール名前空間内の2つの異なるタイプで同じレコードフィールド名を持つ方法はありません。
• Haskellはデフォルトで遅延評価を行います。これはしばしば素晴らしいことですが、時には厄介な方法で噛みつくこともあります。自明ではない状況で怠laな評価を単純に使用すると、不必要なパフォーマンスのボトルネックが生じる可能性があり、内部で何が起こっているのかを理解することは簡単ではありません。
• 遅延評価（特に純度と積極的に最適化するコンパイラとの組み合わせ）も、実行順序について簡単に推論できないことを意味します。実際、特定のコードが特定の状況で実際に評価されるかどうかさえわかりません。結果として、Haskellコードのデバッグには異なる考え方が必要になります。コードをステップ実行するだけでは意味がなく、意味がありません。
• Haskellの純度のため、副作用を使用してI / Oなどを行うことはできません。モナドと「乱用」遅延評価を使用して対話性を実現し、I / Oを実行する可能性のある場所にモナドコンテキストをドラッグする必要があります。（これは実際には多くの点で優れた機能ですが、実際的なコーディングは不可能な場合があります。）

Haskellの欠点の大部分（およびHaskellの欠点のほとんど）は、その2つの明確な特徴に由来しています。それは、怠zyで純粋に機能的です。

怠zyであると、パフォーマンスについて推論するのが難しくなります。特に、怠に慣れていない人にとっては、経験豊富なHaskellerであっても、特定の場合に怠inessがパフォーマンスにどのように影響するかを確認するのは困難です。

怠azineは、Criterionのようなライブラリを使用せずに正確なベンチマークを作成することがより困難であることも意味します。

純粋に機能的であるということは、変更可能なデータ構造を使用する必要があるときはいつでも（それらなしでは目的のパフォーマンスを達成できない場合-考えられるほど頻繁には発生しないGHCのオプティマイザーのおかげで） IO（またはST）モナドに引っかかっているため、コードが面倒になります。

速度を目標の1つとして挙げたので、手で最適化されたHaskellコードと、パフォーマンスをあまり考慮せずに記述されたHaskellコードとの間には、パフォーマンスに大きな違いがしばしばあることを指摘する必要があります（他の言語よりも）。そして、手で最適化されたHaskellコードはしばしば非常にいものです（他のほとんどの言語でも同様であると思いますが）。

私はHaskellの専門家ではありません。基本を学びましたが、残念ながらHaskellで本格的なプロジェクトを行う機会がありませんでした（この言語が大好きなので、私はしたいです）。

しかし、私が知っていることと、関数型プログラミングに非常に近い分野で働いている人との議論から、グラフアルゴリズムを実装したい場合、Haskellは最良の解決策ではないかもしれません。グラフ構造の多くの局所的な変更。

グラフは一般に再帰構造を持たないため、私の考えでは、構造とそれらの間のポインターを使用してグラフのコピーを1つ作成し（C ++でできるように）、ポインターを変更してそのコピーを操作します。ノードの作成または破棄など。

Haskellでの私の知る限り、上記の表現/アプローチを使用することは不可能なので、Haskellでこのようなデータ構造と操作を適切に処理する方法を疑問に思います。この記事では、Haskellのグラフアルゴリズムに関するいくつかの問題について簡単に説明します。

編集

最近、関数型プログラミングの専門家と話をして、特定のグラフアルゴリズムを効率的に実装することはHaskellでは非常に難しいことを確認しました。

Haskellの欠点は、その違いです。これは、より一般的に教えられたり話されたりする言語から大きく離れているため、学習曲線が大きくなります。また、行き詰まった場合にヘルプの利用可能性を制限する可能性のある言語ではあまり人気がありません。これらは実際には大きな欠点ではありません。

潜在的な欠点の1つは、関数型言語であるため、特定の問題ドメインではあまり役に立たないことですが、これはオブジェクト指向言語でも同様です。一般に、少なくとも比較的人気のある言語については、言語には学習曲線を超える真の否定はありません。言語がチューリング完全である限り、理論的には何でも可能です。

だから、これを考えると、私が探しているのは、Haskellに付随する欠点や問題です

「Haskellの問題」は特定のドメインで発生する傾向があります。Haskellはアプリケーションプログラミングのための素晴らしい言語であり、他の何よりも書くのがはるかに快適です。次のような、サポートが不十分なことをしようとすると、問題が発生する傾向があります。

• クロスコンパイル。GHCはクロスコンパイラとして構築できますが、プロセスはかなり複雑です。
• 組み込みアプリケーション。Haskellにはガベージコレクターによるメモリ管理があるため、これはそれほど驚くことではありません。
• 速度。HaskellはRustほど高速ではありませんが、ほとんどの場合、かなり競合します。アプリケーションドメインに大きく依存します-純粋な計算は最適化されますが、「ファイルをバッファに読み込んで行数をカウントする」などはHaskellで表現するのが困難です。