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

Question

私は次の（比較的簡単な）個人的なプロジェクトのためにHaskellに飛び込んでいます。私がHaskellに取り組んでいる理由は次のとおりです。

純粋に関数型の言語を理解する
速度。これは議論の余地があると確信していますが、私が見たプロファイリングはHaskellをC++に近づけています（Erlangよりもかなり速いようです）。
速度。 Warp Webサーバーは実質的に他のすべてのものに比べて非常に高速のようです。

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

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

tdammers · Accepted Answer

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

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

sepp2k · Answer

Haskellの欠点のほとんど（およびHaskellの利点のほとんど）は、2つの明確な特徴から来ています。

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

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

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

目標の1つとして速度を挙げたので、手動で最適化されたHaskellコードと、パフォーマンスをあまり考慮せずに（他の言語よりも）書かれたHaskellコードのパフォーマンスには大きな違いがあることが多いことを指摘しておきます。そして、手作業で最適化されたHaskellコードは、しばしば非常に見苦しくなります（他のほとんどの言語でもそうだと思いますが）。

Giorgio · Answer

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

しかし、私が知っていることと、関数型プログラミングに非常に近い分野で働いている誰かとの議論から、グラフアルゴリズムを実装する場合、Haskellは最適なソリューションではない可能性があります。グラフをウォークスルーし、グラフ構造に対して多くのローカル変更を実行します。

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

Haskellでの私の知識では、上記の表現/アプローチを使用することはできないため、Haskellでこのようなデータ構造と操作を適切に処理するにはどうすればよいのでしょうか。 Haskellのグラフアルゴリズムに関するいくつかの問題について、簡単に説明しますこの記事

[〜＃〜]編集[〜＃〜]

私は最近関数プログラミングの専門家と話をしました、そして彼は特定のグラフアルゴリズムを効率的に実装することはHaskellでかなりトリッキーであるかもしれないことを確認しました：CまたはC++で行うようにポインターを移動することははるかに速くなることができます。

Ryathal · Answer

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

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

user275647 · Answer

だから、これを考えると、私が探しているのはHaskellに伴う欠点または問題です

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

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