大学での4年間、私たちはいくつかの関数型プログラミング言語で多くの関数型プログラミングを使用してきました。しかし、私はまた多くのオブジェクト指向プログラミングを使用してきました。実際、自分の小さなプロジェクトを行って最初の仕事を準備するときには、オブジェクト指向言語をより多く使用します。しかし、これらのプロジェクトを行うときは、関数型プログラミング言語でコーディングしたかったことがよくあります。

ただし、仕事を探しているときに、関数型プログラミング言語の知識が必要な仕事を見つけることは非常にまれです。

なぜ関数型プログラミング言語は業界でもっと使われないのですか？最近では関数型プログラミング言語についてかなりのニュースがありますので、関数型プログラミングは今業界で流行しているのでしょうか？

関数型プログラミングがあまり普及していない理由の1つは、知識ベースの不足だと思います。私の経験では、企業はメインストリームではないテクノロジーの実装に関して非常にリスク回避的であり、実証済みの真のフレームワーク（java、c ++、c＃）に投資したいと考えています。新しいパラダイムが考慮されるのは、ビジネス上のニーズがある場合（エリクソンなど）に限られます。しかし、エリクソンの場合でさえ、管理者はc ++の使用を要求し、ジョーアームストロングはc ++でアーランコールをコーディングすることを余儀なくされたと聞きました!! これは、企業が新しいテクノロジーを実装することに消極的であることを示しているはずです！

私は教授でしたが、プログラマと同じように、教授は常に次の大きなものを探しています。彼らが見つけたと思うと、彼らはそれを時流にし、誰もが山積みになります。教授は本当に賢いに違いないと考える学生に説教しているので、それ以外の理由で教授になるのであれば、抵抗はありません。

関数型プログラミングはそのような時流です。確かに、調査すべき興味深い興味深い質問がたくさんあり、興味深い会議の記事がたくさんあります。それは特に新しいアイデアではありません、そしてあなたはちょうどどんな現代の言語でもそれをすることができます、そして、アイデアは面白いために新しいものである必要はありません。持っているのも良いスキルです。

それを考えると、関数型プログラミングは、OOPが唯一のものではないように、矢筒に持つべき1つの矢印であり、唯一のものではありません。

私のコンピュータサイエンスアカデミアの牛肉は、実際に何が現実世界の理にかなっているのか、つまり品質管理を決定するための、産業界との実際的な相互作用の欠如です。その品質管理があった場合、最新の時流だけでなく、トレードオフで問題とそれらの解決策の範囲を分類することに別の重点があるかもしれません。

最近のソフトウェア開発における最大の問題は、複雑さを管理する能力だからです。これは、ほとんどの関数型プログラミング言語の焦点では​​ありません。そのため、言語ない優先順位（すなわち、より人気のOOP言語）ことを確認だけで、よりアカデミックな関数型言語から出てくるクーラー機能のいくつかを盗み、その上に滞在する傾向があります。

関数型プログラミングが確実に定着し始めています-ゆっくりですが確実に。

たとえば、私が構築しているスタートアップは、次の理由から、主要な開発言語として関数型言語（Clojure）を使用しています。

• 生産性 -FPの学習は難しいですが、一度慣れてしまえば、力と表現力の点で勝つことは非常に困難です。私はおそらく、C＃やJavaで必要だったものと比較して、特定の機能を実装するための行数の約1/10を書いています。

• 信頼性 -純粋な関数は、ステートフルオブジェクトよりも推論とテストがはるかに簡単です。したがって、より適切なテストを記述し、コードの正確性をより簡単に検証できます。

• 並行性-関数型言語は不変性を強調します。不変性は、複数のコアで効果的に実行する必要があるよりも、並行アプリケーションにとって大きな利点があります。好むと好まざるとにかかわらず、複数のコアで実行することは未来です。http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickeyをご覧ください。これがなぜそれほど重要なのかについての簡潔な説明があります。

• 構成可能性/モジュール性 -関数型言語は、複雑なオブジェクト指向システムよりも簡単にコンポーネントを接続するのに役立つようです。私はまだこれのすべての理由を理解していませんが、その一部は、OOモデルが引きずるすべての「偶発的な複雑さ」を持っていないという事実に由来します。スチュアート・ハロウェイによるラジカル単純性に関する講演では、これらのアイデアをさらに深く掘り下げています。

編集：Despertarのコメントに応えて、モジュール性を制限するOOPシステムの「偶発的な複雑さ」の例は、ディープクローニング対浅いクローニングの問題です。オブジェクトを一緒に構成して、非常にクローニングと突然変異のセマンティクスの慎重な分析。小さなケースではこれは管理可能ですが、複雑なシステムでは急速に重大な問題になります。純粋に機能的なデータ構造に依存している場合、この問題はそもそも存在しません。

キラーアプリの欠如

ねえ、ここの上のこれは新鮮に見えます。（掘る掘る）

ほとんどのプログラミング言語は、「キラーアプリ」を持っていることで繁栄したと思います。これは、その言語に限定された（またはそのように見た）魅力的なものです。これは、すべての受け入れがそのアプリケーションであったと言うことではなく、それが言語をより大きな受け入れへと駆り立てたということです。

以下は、現在ある言語のいくつかを採用するきっかけとなったニッチについての私のあまり正確ではない見解です。

• C：どこでも動作します（これは70年代後半と80年代後半でした）
• C ++：GUIフレームワーク（90年代前半）
• Java：アプレットとサーブレット（90年代後半）
• Objective-C：iOSアプリ（それ以前のOS Xアプリ）
• Ruby：Rails
• C＃：ASP.NET、WinForms
• PHP：Wordpressなど
• JavaScript：AJAX、特にフレームワーク経由
• lua：ゲームスクリプティング、特にすごい

それとは別に、多くの専有言語は強力な販売組織（Oracle、およびそれよりも程度は低いがMicrosoftの言語）を通り抜けて、独自のニッチを効果的に生み出しています。

このリストに関する1つの非常に重要な注意：キラーアプリで示されているように、言語の「ニッチ」は、数十年が経過するにつれてますます具体的になります。リストの最後の1つ、具体的にはGame scriptingに注意してください。他の言語によって既に十分に行われていることのリストのために、言語が注目を集めるのはますます難しくなっています。

したがって、関数型言語が実際に離陸する必要があるのはニッチです。実際には、巨大な関数型言語はまだありませんが、小さなニッチにはたくさんあります。

• Emacs Lisp：開発者によるEmacsの80年代以降の継続的な使用。（他のどこでもほとんど使用されません。）
• Erlang：多数の同時エージェントが必要な場所。
• スキーム：教育
• APL / J / K：ファイナンス（議論のために、これらを関数型と呼びましょう）
• Common Lisp：「AI」-これは、人々がそれが使われていると言う傾向があるものであり、祝福と呪いです。

さて、この議論から除外したと思う唯一の主要言語はPythonです。Pythonは非常に興味深いことをしました。主要なニッチで勝者とは思えずに成功しました。これは、私がこのように言語の人気を見るのはまったく間違っていることを意味する可能性があります。また、採用と受け入れを促進するキラーアプリがなくても十分に優れた言語が普及する可能性がありますが、それは非常に難しく、非常に長い時間がかかる可能性があります。（Perlにも同様の話がありますが、数年前に登場し、現在ではあまり普及していません。）

このことから、私は私が考える機能どの言語と言うことができます増加傾向に：

• Clojure：Webプログラミング、特に Heroku経由
• Scala：Lift（最近はPlayかもしれません）-JavaなしのJVM

人気のある関数型言語を次に探す場所を尋ねられたら、ターンキークラウド開発（HerokuまたはGAE）またはターンキーモバイルアプリ開発を備えた関数型言語に目を光らせてください。

同じ理由で、Lispが実際に流行りませんでした（フレーム戦争を始めましょう！）。関数型プログラミングは、命令型およびオブジェクト指向プログラミングと比較して、非常に異質なパラダイムです。大部分のCS学生のように、Cから始めてC ++ / Javaに進んだ場合、通常の考え方とは完全に直交するような考え方を学ぶことを望まない傾向があります。

ビジネスとプログラミングについて考えてみましょう。

ソフトウェアを戦略的資産として使用する企業があります。これは典型的ではありません。ほとんどの企業にとって、ITは企業の実際のビジネスをサポートするものです。それは必要な費用です。彼らは、$ Xで必要なITを手に入れることができることを知っているため、保守的です。

さらに、企業では、最も安いことは通常、昨日やったことです。ただし、変更は望ましいことですが、費用がかかります。たとえば、企業がC＃/。NETソリューションからF＃に変更された場合、問題が発生します。彼らのプログラマー（おそらく最も鋭いプログラマーではない）は、新しい言語を習得し、両方に習熟し、両方を頻繁に使用する必要があります。両方で長い間書かれたルーチンがあるでしょう。Haskellのようなものに移行する場合、または最初にC ++ / MFCを使用している場合、彼らはより多くの変更を行うことになり、それははるかに高価になります。

また、C＃プログラマーの供給が予定されており、今後もマイクロソフトのサポートが継続されます。現在のITプラクティスは信頼できます。プログラマーの継続的な可用性の制度的サポートや保証のレベルは同じではありません。

したがって、ほとんどのビジネスでは、関数型プログラミングに変更を加えることは初期費用がかかり、長期的にはITコストの削減が十分である場合にのみ支払われます。

あなたはすでに機能的なスタイルでコードを書いていますが、あなたはそれを知りません。

コードの単体テストを作成する必要がある場合、テスト可能な関数を作成する傾向があります。これは、副作用を作成または依存せず、常に同じ引数で同じ結果を返します（いわゆる純粋関数）。これは、機能プログラムの主な利点です。

関数型言語は制限が多すぎると思います。したがって、命令型言語を関数型に置き換える代わりに、命令型言語は関数型の機能を取得します。現在、ほとんどすべてのプログラミング言語にはクロージャーとラムダがあります。

あなたの質問に対する本当の答えは1つだけだと思います。この答えが当てはまる理由はたくさんありますが、それらは異なる質問です。

ここにあります：

• ソフトウェアアーキテクトは、自信を持って機能するソリューションを提供します。
• アーキテクトの大部分は関数型言語で働いていません。
• テクノロジーと言語が選択されると、企業はそれらと連携できる人材を見つけます。

流行ってる？それはすべて、関数型言語の使用に自信のある人がアーキテクトになり、作業中のプロジェクトでそれを使用することを選択するかどうかに依存します。

本当の問題は状態です。

関数型言語にはグローバルな状態はありません。ほとんどの産業上の問題は、小規模の一部の機能が実際にそれを必要としない場合（元帳の処理）でも、大規模な状態（元帳または一連のトランザクションをどのように表すか）を必要とします。

ただし、本質的にステートフルなVon-Neumanアーキテクチャマシンでコードを実行しています。したがって、私たちは実際に状態を取り除くことはしていません。関数型言語は、状態の複雑さを開発者から隠すだけです。これは、言語/コンパイラが舞台裏の状態を処理し、管理する必要があることを意味します。

したがって、関数型言語にはグローバルな状態はありませんが、それらの状態情報はパラメーターと結果として渡されます。

それでは、言語は感覚の背後にある状態を効率的に処理できるのでしょうか？特に、データサイズがアーキテクチャのサイズをはるかに超える場合。

ハードウェア側から見る

OSは、ここ数年でアドレス空間を視覚化するのに大いに役立ちました。そのため、アプリケーションは公式に心配する必要がありません。ただし、メモリの負荷が激しくなると、心配しないアプリケーションはハードウェアをスラッシングするトラップに陥ります（ハードウェアをスラッシングすると、プロセスのクロール速度が低下します）。

プログラマーは関数型言語の状態を直接制御できないため、これを処理するためにコンパイラーに依存する必要があり、これをうまく処理する関数型言語を見たことはありません。

コインの反対側では、ステートフルプログラマーが状態を直接制御できるため、メモリ不足の状態を補うことができます。私は実際にそうするのに十分賢いプログラマーをあまり見ませんでしたが。

産業側から見ると：

業界には、非効率的なステートフルプログラマがたくさんあります。

しかし、これらのプログラムの改善を長期にわたって測定するのは簡単です。開発者のチームに、プログラムが状態を処理する方法を改善することでコードを改善できる問題を投げかけます。

関数型プログラムの場合、プログラムを改善するツールを改善する必要があるため、改善を測定するのはより困難です（ここでは、プログラムの全体的な改善ではなく、アプリケーションが根本的な状態を効率的に処理する方法を検討しています）。

業界にとっては、コードの改善を測定する能力に帰着すると思います。

雇用の観点から

雇用できるスタットフルプログラマーがたくさんいます。関数型プログラマーを見つけるのは難しいです。したがって、業界が機能的なスタイルのプログラミングに切り替わった場合、基本的な需要と供給のモデルが作動しますが、それは望んでいることではありません（プログラマーはそれなりに高価です）。

この質問の前提は少し間違っています。次の理由により：

1. 関数型プログラミングは実際、業界ではかなり一般的です。ただし、経験豊富なプログラマーが利用できる場合にのみ使用されます。初心者はそれを知ることを期待することはできません。ほぼすべての大規模なプログラミングプロジェクトで使用されていますが、経験豊富なプログラマーが扱う領域に保持しています。初心者は、関数型プログラミングを必要としない簡単なモジュールを扱います。
2. この現実を考えると、人々（通常は大学出身の若い人たち）を雇用している企業は、関数型プログラミングの経験を本当に求めることはできません。関数型プログラミングを必要とするプロジェクトに参加している人は、すでに15年間同じ会社にいます。
3. 関数型プログラミングの知識が30年後に非常に役立つことをすでに知っているため、大学はそれを教え始めています。彼らの時間範囲は30年であり、企業のような通常の半年ではありません。
4. これらのポイントは、人々が労働力に就くときに失望し、大学で学んだことは使われないことを見る理由です。しかし、彼らは30年の期間のために設計されており、最終的には有用になるでしょう-それはちょうど企業が人々が知っていると期待できるもの-シンプルなものを使用しているということです。
5. また、数年の大学卒業後、実際のソフトウェアプロジェクトで機能プログラミングを使用するのに十分な知識があると考えると、you慢になります。最初に単純なものから始めます。作業を開始するときに、最も複雑なソフトウェアを最初のタスクとして実行する必要はありません。最終的には複雑なものに到達しますが、時間がかかります。

FPのデバッグが難しいためです。