関数型プログラミングに対するあなたの最も強い意見は何ですか？[閉まっている]

関数型プログラミングは、最も古いプログラミングパラダイムの1つです。ただし、より一般的なパラダイムと比較して、業界ではあまり使用されていません。しかし、それは主に学界で強調されてきました。

関数型プログラミングに対するあなたの最も強い意見は何ですか？

問題は、ほとんどの一般的なコードが本質的に状態に関係していることです-ビジネスアプリ、ゲーム、UIなど。アプリの一部が純粋に機能していても問題はありません。実際、ほとんどのアプリは少なくとも1つの分野で利益を得ることができます。しかし、パラダイムをあちこちに強制することは直感に反します。

関数型プログラミングの問題は、関数型プログラミング自体ではありません。それを行うのはほとんどの人であり、それを行う言語を設計する（最悪の）人のほとんどです。

問題は、非常に頭が良い（ときどき素晴らしい）にもかかわらず、あまりにも多くの人々が、純粋さ、完璧さ、そして自分自身の（しばしばかなり狭い）世界観の強制と、言語とそれを使用するすべての人。

結果の1つは、妥協の失敗です。これにより、（特に）およそ10,000の言語と方言が作成されます。これらは、他の言語よりも真に重要な利点を得るために、迷惑をかけるほど十分に異なります。多くの人は現実の世界も見て、機能モデルにうまく適合しないため、基本的には間違っているだけで無視するのが最善だと判断します。

妥協することができないため、特定の種類の問題（またはいくつかの特定の種類の問題）には絶対的に美しいが、他の多くの言語には本当にひどい言語がたくさんあります。その一部はおそらく機能モデル自体によって引き起こされますが、もっと多くのことは（少なくとも私には）、この領域に最初から惹かれている基本的な性格タイプによって引き起こされているようです。

それは多くの問題につながります。まず第一に、「関数型プログラミング」を学ぶことはほとんど哲学的な価値があります。他のほとんどの種類の言語では、特定のジャンルの1つの言語を知ることは、別の言語を学ぶのに非常に役立ちます。私のプロジェクトが言語XIを使用している場合、通常、言語Yを知っている（ただしXは知らない）人をかなり安全に雇うことができます。関数型言語では、それはあまり真実ではありません。Erlangをよく知っているかもしれませんが、それでもHaskellモナドは完全に外国語であり、理解できないものです。

言語の数と才能の限られた移植性を組み合わせると、い状況に陥ります。1つの言語または方言が、それを合理的な一般使用に必要な「クリティカルマス」を形成することはほとんど不可能です。それはゆっくりと変化するが、それはまだ支配的なデスクトップOSになってLinuxのような多くのです-毎年、人々はそれを引数説得を思い付く最後にこれがあることを行っている年を-と、ちょうどそのすべてのを予測してきた人のように数十年の今、彼らは再び間違っているでしょう。それは（どちらか一方が）決して起こり得ないということではありません。予測を見て「今年ではない」と思う人々がこれまでのところ正しかったというだけです。

関数型プログラミングがあまり広く使われていない理由は、それがあなたの邪魔になりすぎるからだと思います。たとえば、LispやHaskellを「この言語全体が1つの大きな抽象化の反転である」と言わずに真剣に調べることは困難です。必要なときにコーダーが取得できないベースラインの抽象化を確立するとき、言語では単純にできないことを確立し、言語がより機能的であるほど、これらが多くなる傾向があります。

たとえば、Haskellを考えてみましょう。機能的純度という名のもとに、状態とI / Oを管理するために、誰も理解していない脳を破壊する抽象化の反転を使用する必要があります。 それは速く老化します。

すべての敬意を払って、私はあなたの質問が不適切であると思います。関数型プログラミングはツールであり、特定の種類の問題を解決するのに役立つツールのセットです。それについて意見を持つことは、特定の問題またはアプリケーションのコンテキストでのみ意味があります。一般的にそれに対して意見を持つことは、ペンチやレンチに対して意見を持つようなものです。

たとえそれを習得したとしても、広く理解されていないという単純な理由で商用製品に関数型言語を使用することに気が進まない可能性があります。時間をかけて維持または拡張すること。

それは考えられないことではなく、実際のハッキングスキルのないjavaschool卒業生はそのタイプのプロジェクトのどこから始めればよいかわからないので、おそらくより高い水準の開発者になるでしょうが、有能な開発者の限られたプールは確かに必要な考慮事項ですビジネスの観点から。

市場投入までの時間

手続きコードとマントラの完全なITランドスケープを取り除くことは困難です。

まず第一に、ステートフルプログラミングとfpに関する引数を受け入れません。haskellでStateモナドを調べると、コードに対する状態の影響を評価する興味深い新しい方法がいくつか見つかります。

私がfpに対して有意義な議論をするなら、haskellのような深刻な関数型言語を学ぶことはフォーミュラ1の車を運転することを学ぶことに似ているでしょう... 、あなたの同僚はカムリを運転していて、喜んでそうしています。fpに優しい環境で仕事を見つけることは依然として非常に困難であり、自力で努力したり、fpの有名な実務家を探したりしない限り、この変化は見られません。

私の答えは私をfp fanboyとして見せてくれると思います。haskellのような実際のfp言語を真剣に試すことをお勧めします。

私は大ファンであり、関数型プログラミングの擁護者です。しかし、ここに私のポイントがあります：

• 習得しやすい
  pythonやruby（および他の多くの言語）などのプログラミング言語は習得が容易です。Haskell、Agda、Coq、ATSなどの言語を使用した高度な関数型プログラミングを学ぶのは非常に困難です。「数学構造化プログラミング」という用語を使用する人もいます。カテゴリ理論と抽象数学に精通していれば簡単ですが、たとえば「モナド」が何であるか手掛かりがなければかなりの仕事があります。

• スクリプト言語を使用してプログラミングすると、生産性が向上します。
  状況によっては、pythonやrubyなどのスクリプト言語を使用すると、生産性が向上する場合があります。これは、さまざまなパッケージまたはライブラリを高速プロトタイピングおよび接着することを意味しています。このコンテキストでは、動的言語（動的オブジェクト指向プログラミングなど）を使用することもできます。通常、静的型付けの方が優れていますが、動的型を使用したスクリプトを作成すると、プラスの効果が得られます。

• ビジネス上の考慮事項
  プログラミングは、成功するソフトウェアプロジェクトのほんの一部です。ソフトウェアは機能しなければならず、ユーザーは満足する必要があり、これは必ずしも使用するプログラミング言語に依存するわけではありません。管理者は、新しいテクノロジとプログラミング言語を評価する際に、利点とリスクを考慮する必要があります。新しいプログラマーは新しいプログラミング言語をすばやく習得できますか？会社でこの技術を使用した経験はありますか？リスクはありますか？これは上級管理職と議論するのは難しいでしょうか？

ビジネスの文脈では、関数型プログラミングは、コアソフトウェアコンポーネントに追加するシステム（たとえば、ミッションクリティカルではないコンポーネント）で使用できます。たとえば、コアソフトウェアをほとんど変更しないが、新しいプログラミング言語で新しい部分（GUI、監視ソフトウェアなど）を追加する銀行。（例外があるかもしれませんが、これは銀行での私の経験です。）

さらに、関数型プログラミングは、正式な検証がメリットまたは必須の場合に非常に役立ちます。

FPは便利なパラダイムとしては反対していませんが、プログラミング言語で利用できる唯一のパラダイムとしては反対しています。

多くの問題を解決するのに利点があります。ただし、FPはCなどの手続き型言語に適用できます。

1. （そして最も重要なこと）プログラマーの労働力はそれらの言語やスタイルで訓練されていません
2. 機能的エバンジェリストの多くは、機能的販売を試みているため、a-holesまたはfruitcakesとして出てきます。a-holeが好きな人はいませんし、フルーツケーキの後ろにお金を投げる人もいません。心を込めて、私は本当に機能的なものが好きで、それを引き込みたいと思っていますが、私は職場でトレーニングにお金をかけずに開発することができる唯一の人であることを知っています（ハードセル）、そしてほとんどすべての良い読者の話を参考にする。

数百のコアがあり、ロックがスケールしないという認識に達すると、機能するようになります。次に、ネストされたデータパラレルが「ビッグアイロン」プログラムに進む唯一の方法になり、機能的に優れています。

FPは、パフォーマンスを無視しながら素敵な短いプログラムを書くのがクールだからです。現実の世界では、これに対する陰謀はありません。また、たとえば、いくつかの要素（たとえば、基数の並べ替え）を実装すると、FPの全体的な痛みのように見えます。ああ、生成されたコードはIMHExperience sloooooooooooooooooooowです。

学習曲線が非常に急で、時間がかかるものもあります（特にOOPから来た場合は、パラダイムシフトを得る前に頭を数回くちばしにします）。

関数型プログラミング（JavaからClojureに移行）を開始しましたが、それでもかなり難しいと感じています。コミュニティは、Javaほど表現力のあるコードを作成していないようです。

表現力のわずかな損失と複雑さのわずかな増加があるようです。

関数型プログラミング言語の経験はほとんどありませんが（HaskellとLispを知っています）、FPパラダイムは非常に強力で、他のパラダイムよりもエレガントであることが多いと思います。FPを使用して本格的なプロジェクトに取り組む機会があればいいのにと思います。

FPの有効性に関して深刻な疑念を抱いている唯一の領域は、誘導的に定義できない複雑なデータ構造（グラフなど）をどのように処理できるかです。たとえば、大きなグラフで動作するアルゴリズムを実装しなければならない場合、おそらくグラフを歩いて小さなローカル変更を行うと、FPアプローチはプログラムがノードからポインターを使用するノード。