ここでは、関数型言語などについて多くの話が見られます。なぜ「伝統的な」言語よりも 1 つを使用するのですか? 彼らは何をより良くしますか?彼らは何が悪いのですか?理想的な関数型プログラミング アプリケーションとは?
48 に答える
関数型言語は、命令型言語やオブジェクト指向言語とは異なるパラダイムを使用します。それらは、言語の基本的な構成要素として、副作用のない関数を使用します。これにより、多くのことが可能になり、多くのことがより困難になります (または、ほとんどの場合、人々が慣れ親しんだものとは異なります)。
関数型プログラミングの最大の利点の 1 つは、副作用のない関数の実行順序が重要ではないことです。たとえば、Erlang では、これは非常に透過的な方法で並行性を有効にするために使用されます。また、関数型言語の関数は数学関数と非常によく似た動作をするため、それらを関数型言語に簡単に変換できます。場合によっては、これによりコードが読みやすくなります。
従来、関数型プログラミングの大きな欠点の 1 つは、副作用がないことでもありました。IO なしで有用なソフトウェアを作成することは非常に困難ですが、IO を関数に副作用なしで実装することは困難です。したがって、ほとんどの人は、単一の入力から単一の出力を計算する以上に、関数型プログラミングから得たことはありません。F# や Scala などの最新の混合パラダイム言語では、これは簡単です。
現代の言語の多くには、関数型プログラミング言語の要素が含まれています。C# 3.0 には多くの関数型プログラミング機能があり、Python でも関数型プログラミングを行うことができます。関数型プログラミングの人気の理由は主に次の 2 つの理由によると思います。そして、言語はよりアクセスしやすくなっています。
プログラミングへの関数型アプローチが「人気を博している」ことに疑問の余地はないと思います。なぜなら、それは (プログラミングのスタイルとして) 約 40 年間使用されてきたからです。OO プログラマーが不変オブジェクトを優先するクリーンなコードを作成するときはいつでも、そのコードは関数の概念を借用しています。
ただし、関数型スタイルを強制する言語は最近、多くの仮想インクを取得しており、これらの言語が将来的に支配的になるかどうかは未解決の問題です. 私自身の推測では、 ScalaやOCamlなどのハイブリッドなマルチパラダイム言語 は、純粋な OO 言語 (Smalltalk、ベータ版など) が主流のプログラミングに影響を与えたが終わっていないのと同じように、「純粋な」関数型言語を支配する可能性が高いということです。最も広く使用されている表記法として挙げられます。
最後に、FP に関するあなたのコメントは、数年前に手続き型プログラマーから聞いたコメントと非常に類似していることを指摘せずにはいられません。
- (神話的、私見)「平均的な」プログラマーはそれを理解していません。
- それは広く教えられていません。
- それを使用して作成できるプログラムは、現在の手法を使用して別の方法で作成できます。
グラフィカル ユーザー インターフェイスと「ビジネスのモデルとしてのコード」が OO をより広く評価するのに役立った概念であったのと同様に、不変性とより単純な (大規模な) 並列処理の使用を増やすことで、より多くのプログラマーが関数型アプローチが提供する利点を理解するのに役立つと私は信じています。 . しかし、デジタル コンピューター プログラミングの全歴史を構成する過去 50 年ほどの間に私たちが学んだことと同じくらい、私たちはまだ学ぶべきことがたくさんあると思います。今から 20 年後、プログラマーは、現在人気のある OO 言語や FP 言語を含む、現在使用しているツールの原始的な性質を驚かせて振り返るでしょう。
私にとっての主なプラスは、特に現在、より多くの MHz から離れてより多くのコアに向かっているため、その固有の並列性です。
それが次のプログラミング パラダイムになり、OO 型のメソッドを完全に置き換えるとは思いませんが、コードの一部を関数型言語で記述するか、汎用言語を使用する必要があるという点に到達すると思います。より機能的な構造を含むように成長します。
専門的に関数型言語を扱ったことがない場合でも、関数型プログラミングを理解することで、より優れた開発者になることができます。これにより、コードとプログラミング全般について新しい視点が得られます。
学ばない理由はないと言っています。
関数型と命令型のスタイルを上手に組み合わせた言語は、最も興味深く、成功する可能性が最も高いと思います。
私はネクスト・ビッグ・シングについて常に懐疑的です。多くの場合、ネクスト ビッグ シングは、テクノロジーが優れているかどうかに関係なく、適切なタイミングで適切な場所に存在するという歴史の純粋な偶然です。例: C++、Tcl/Tk、Perl。すべての欠陥のあるテクノロジーは、当時の問題を解決するか、確立された標準とほぼ同じである、またはその両方であると認識されたため、すべて大成功を収めました。関数型プログラミングは確かに優れているかもしれませんが、採用されるとは限りません。
しかし、人々が関数型プログラミングに興奮している理由はわかります。多くの非常に多くのプログラマーが、関数型言語を使用すると生産性が 2 倍 (または 10 倍) 向上することを発見した一種の「変換経験」を持っています。変更に対する回復力が高く、バグが少ないコード。これらの人々は、関数型プログラミングを秘密兵器と考えています。この考え方の良い例は、Paul Graham のBeating the Averagesです。ああ、そして彼のアプリケーション?e コマース Web アプリ。
2006 年の初めから、関数型プログラミングと並列処理についても話題になっています。Simon Peyton Jonesのような人々は、少なくとも 1984 年以来、並列処理について断続的に心配してきたので、関数型言語がマルチコアの問題を解決するまで、息をのむことはありません。しかし、それは現在の追加の話題のいくつかを説明しています.
一般的に、アメリカの大学は関数型プログラミングを教えるのに不十分な仕事をしています。Scheme を使用したイントロ プログラミングを教えるためのサポートの強力なコアがあり、Haskell もそこでサポートを楽しんでいますが、関数型プログラマーの高度なテクニックを教える方法はほとんどありません。私はハーバードでそのようなコースを教えたことがあり、この春、タフツで再びそうする予定です. Benjamin Pierce は Penn でそのようなコースを教えています。ポール・ハダックがイェール大学で何かをしたかどうかはわかりません。ヨーロッパの大学ははるかに優れた仕事をしています。たとえば、関数型プログラミングは、デンマーク、オランダ、スウェーデン、および英国の重要な場所で強調されています。オーストラリアで何が起こっているのか、私はあまり感じていません。
ここの部屋で象について言及している人は誰もいないので、それは私次第だと思います:)
JavaScriptは関数型言語です。ますます多くの人々がJSでより高度なことを行うようになり、特にjQuery、Dojo、およびその他のフレームワークのより細かい点を活用するにつれて、FPはWeb開発者のバックドアによって導入されます。
クロージャーと組み合わせることで、FPはJSコードを非常に軽量にし、それでも読みやすくします。
乾杯、PS
ほとんどのアプリケーションは、通常の OO の方法で解決できるほど単純です。
オブジェクト指向の方法は、常に「正常」であるとは限りません。この 10 年間の標準は、過去 10 年間の周縁化された概念でした。
関数型プログラミングは数学です。Paul Graham on Lisp (Lisp を関数型プログラミングに置き換えます):
この 1950 年代の言語が時代遅れにならない理由を簡単に説明すると、それはテクノロジーではなく数学であり、数学は古くならないからです。Lisp を比較するのに適しているのは、1950 年代のハードウェアではなく、たとえば、1960 年に発見され、現在でも最速の汎用ソートであるクイックソート アルゴリズムです。
あなたが使ったとき、あなたは関数型プログラミングだとは知らなかったに違いありません:
- Excelの数式
- Quartz Composer
- JavaScript
- ロゴ(タートルグラフィックス)
- LINQ
- SQL
- Underscore.js(またはLodash)、D3
平均的な企業プログラマー、たとえば私が一緒に働いているほとんどの人は、それを理解できず、ほとんどの作業環境ではプログラムを作成できません。
それは時間の問題です。平均的な企業プログラマーは、現在の大物が何であれ学習します。15 年前、彼らは OOP を理解していませんでした。 FPが普及すれば、あなたの「平均的な企業プログラマー」もそれに続くでしょう。
大学ではあまり教えられていない(というか最近は?)
大きく異なります。私の大学では、SML は学生が紹介される最初の言語です。MIT は初年度のコースとして LISP を教えていると思います。もちろん、これらの 2 つの例は代表的なものではないかもしれませんが、ほとんどの大学では、FP をカリキュラムの必須部分にしないとしても、少なくともいくつかのオプションのコースを FP で提供していると思います。
ほとんどのアプリケーションは、通常の OO の方法で解決できるほど単純です。
ただし、「十分に単純」という問題ではありません。FP では、ソリューションはよりシンプルになりますか(または、より読みやすく、堅牢で、エレガントで、パフォーマンスが向上しますか)? 多くのことは「Java で解決できるほど単純」ですが、それでも膨大な量のコードが必要です。
いずれにせよ、FP の支持者は、FP が次の大物であると数十年にわたって主張してきたことを心に留めておいてください。おそらく彼らは正しいかもしれませんが、5、10、または 15 年前に同じ主張をしたときはそうではなかったことを覚えておいてください.
ただし、間違いなく彼らに有利に働くことの 1 つは、最近、C# が FP に向けて急激に変化したことです。その結果、事実上、世代のプログラマーが気付かないうちに FP プログラマーに変わりつつあります。それは、FP「革命」への道を開くだけかもしれません。多分。;)
人は、他の芸術の価値を理解できなければ、自分が選んだ芸術の完全性と不完全性を理解することはできません。ルールに従うことは、テクニックのポイントまでの開発のみを許可し、学生とアーティストはさらに学び、さらに追求する必要があります. 戦略だけでなく、他の芸術を学ぶことは理にかなっています。
他人の活動を見て、自分自身についてもっと学んだことがない人がいるでしょうか? 剣を学ぶにはギターを学ぶ。最初の研究商取引を学ぶために。剣を学ぶだけでは心が狭くなり、外への成長を許しません。
-- 宮本武蔵『五輪書』
ほとんどの現実的な人々は、関数型プログラミングが普及するとは考えていないと思います (オブジェクト指向のような主要なパラダイムになります)。結局のところ、ほとんどのビジネス上の問題はかなりの数学の問題ではなく、データを移動してさまざまな方法で表示するための毛むくじゃらの命令的なルールです。つまり、純粋な関数型プログラミングのパラダイムには適していません (モナドの学習曲線は OO をはるかに超えています)。
OTOH、関数型プログラミングはプログラミングを楽しくするものです。宇宙の根底にある数学の簡潔な表現に内在する時代を超越した美しさを理解させてくれます。関数型プログラミングを学ぶと、より優れたプログラマーになると言われています。もちろん、これは非常に主観的なものです。個人的には、それも完全に真実ではないと思います。
それはあなたをより良い感覚的な存在にします。
関数型言語の重要な機能の 1 つは、ファーストクラス関数の概念です。アイデアは、関数をパラメーターとして他の関数に渡し、それらを値として返すことができるということです。
関数型プログラミングでは、状態を変更しないコードを記述します。これを行う主な理由は、関数を連続して呼び出しても同じ結果が得られるようにするためです。関数型コードは、第一級関数をサポートする任意の言語で記述できますが、Haskell など、状態を変更できない言語もあります。実際、副作用 (テキストの出力など) をまったく行うべきではありません。まったく役に立たないように思えます。
Haskell は代わりに、IO に対して別のアプローチを採用しています: モナドです。これらは、インタープリターのトップレベルによって実行される目的の IO 操作を含むオブジェクトです。それ以外のレベルでは、それらはシステム内の単なるオブジェクトです。
関数型プログラミングにはどのような利点がありますか? 関数型プログラミングでは、各コンポーネントが完全に分離されているため、バグの可能性が少ないコーディングが可能です。また、再帰関数とファーストクラス関数を使用すると、通常はコードの構造を反映した単純な正しさの証明が可能になります。
私は密集している必要がありますが、まだわかりません。F# のような関数型言語で記述された小さなアプリの実際の例はありますか? ソース コードを見て、C# などよりもそのようなアプローチを使用する方が良い方法と理由を確認できますか?
関数型言語についてあなたが言ったことはすべて、ほとんどの人が約 20 年前にオブジェクト指向言語について言っていたことを指摘しておきます。当時、OO について耳にすることは非常に一般的でした。
* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways
変化はどこかから来なければなりません。有意義で重要な変更は、以前のテクノロジで訓練を受けた人々が変更は不要であるという意見を受け入れるかどうかに関係なく、それ自体で実現します。当時、多くの人が反対していましたが、OO への変更は良かったと思いますか?
F#は、Microsoftが推進しているため、追いつく可能性があります。
プロ:
- F#は、VisualStudioの次のバージョンの一部になる予定です
- マイクロソフトはしばらくの間コミュニティを構築しています-著名な顧客と協力する伝道者、本、コンサルタント、MS会議での重要な露出。
- F#はファーストクラスの.Net言語であり、非常に大きな基盤を備えた最初の関数型言語です(Lisp、Haskell、Erlang、Scala、OCamlには多くのライブラリがなく、.Netほど完全ではありません。は)
- 並列処理の強力なサポート
対照:
- C#と.Netに精通していても、F#を開始するのは非常に困難です-少なくとも私にとっては:(
- 優れたF#開発者を見つけるのはおそらく難しいでしょう
したがって、F#が重要になるチャンスを50:50に与えます。他の関数型言語は、近い将来それを実現する予定はありません。
一つの理由は、言語が受け入れられるかどうかの最も重要な部分は、その言語がどれだけ優れているかということだと感じる人がいることだと思います。残念ながら、物事がそれほど単純になることはめったにありません。たとえば、Pythonが受け入れられる最大の要因は、言語自体ではないと主張します(ただし、これは非常に重要です)。Pythonが非常に人気がある最大の理由は、その巨大な標準ライブラリと、サードパーティライブラリのさらに大きなコミュニティです。
ClojureやF#のような言語は、JVM / CLRに基づいて構築されていることを考えると、これに関する規則の例外となる可能性があります。結果として、私には彼らに対する答えがありません。
Lisp や Scheme を学部生として学んだことのない人々が、今それを発見しているように私には思えます。この分野の多くのことと同様に、誇大広告や高い期待を生み出す傾向があります...
合格します。
関数型プログラミングは素晴らしいです。しかし、それは世界を引き継ぐことはありません。C、C++、Java、C# などは引き続き使用されます。
これにより、クロス言語能力が向上すると思います。たとえば、関数型言語で実装してから、他の言語でそのようなものにアクセスできるようにするなどです。
ほとんどのアプリケーションは [お気に入りの言語、パラダイムなどをここに挿入] で解決できます。
これは事実ですが、さまざまなツールを使用してさまざまな問題を解決できます。Functional は、正しく使用された場合により効果的に仕事を行うことを可能にする別の高レベル (より高い?) レベルの抽象化を可能にします。
Epic Games の Tim Sweeney による「The Next Mainstream Programming Language: A Game Developer's Perspective」を読んだとき、最初に思ったのは、Haskell を学ばなければならないということでした。
しばらくの間、物事は機能的な方向に進んでいます。ここ数年の 2 つのクールな新しい子供たち、Ruby と Python はどちらも、以前のものよりも根本的に関数型言語に近づいています。
そして、大規模な並列ハードウェアがすべての人に進化の圧力をかけており、関数型言語が変化に対処するのに最適な場所にあるため、Haskell や F# が次の大きなものになると考えるのは、かつてほど飛躍的ではありません。
複雑さを制御するための最良のツールであるため、人気があります。参照:
- Simon Peyton-Jones のスライド 109 ~ 116、「A Taste of Haskell」の講演
- 「The Next Mainstream Programming Language: A Game Developer's Perspective」 by Tim Sweeney
最近、プログラミング言語の進化を追っていますか? すべての主流プログラミング言語の新しいリリースごとに、関数型プログラミングからより多くの機能が借用されているようです。
クロージャー、無名関数、値としての関数の受け渡しは、かつては Lisp と ML のハッカーだけが知っている風変わりな機能でした。しかし、徐々に、C#、Delphi、Python、Perl、Javascript がクロージャーのサポートを追加してきました。新進気鋭の言語を閉鎖せずに真剣に受け止めることは不可能です。
いくつかの言語、特に Python、C#、および Ruby では、リスト内包表記とリスト ジェネレーターがネイティブでサポートされています。
ML は 1973 年にジェネリック プログラミングの先駆者となりましたが、ジェネリック (「パラメトリック ポリモーフィズム」) のサポートが業界標準になったのは、ここ 5 年ほどのことです。私の記憶が正しければ、Fortran は 2003 年にジェネリクスをサポートし、続いて Java 2004、2005 年に C#、2008 年に Delphi をサポートしました。 .)
これらの機能がプログラマーにとって魅力的な理由は何ですか? プログラマーがより短いコードを書くのに役立ちます。将来的にすべての言語は、競争力を維持したいのであれば、少なくとも閉鎖をサポートする予定です。この点で、関数型プログラミングはすでに主流になっています。
ほとんどのアプリケーションは、通常の OO の方法で解決できるほど単純です。
単純なことにも関数型プログラミングを使用できないと誰が言いますか? すべての関数型プログラムが、コンパイラ、定理証明、または超並列通信スイッチである必要はありません。私は、より複雑なプロジェクトに加えて、アドホックな使い捨てスクリプトに F# を定期的に使用しています。
私の見解では、Microsoftがそれをさらに主流に押し上げた今、それは追いつくだろう。私にとって、それは私たちのために何ができるか、新しい挑戦であり、将来に憤慨する仕事の機会があるため、魅力的です。
習得すると、プログラマーとしての生産性をさらに高めるためのもう1つのツールになります。
うわー、これは興味深い議論です。これに関する私自身の考え:
FP は、いくつかのタスクを比較的単純にします (非 FP 言語と比較して)。非 FP 言語はすでに FP からアイデアを取り入れ始めているため、この傾向は続き、人々が FP への飛躍を容易にするのに役立つマージがさらに見られると思います。
FP には、生産性、信頼性、および保守性の点で大きな利点があるためです。メニーコアは、大量のレガシー コードにもかかわらず、最終的に大企業を切り替えさせるキラー アプリになる可能性があります。並行性と並列性にはうまく適合しません。
「普通の」プログラマーがそれを理解できないことに同意しません。最終的に OOP を理解したのと同じように、彼らはそうするでしょう (それ以上ではないにしても、同じくらい神秘的で奇妙です)。
また、ほとんどの大学では FP を教えており、最初のプログラミング コースとして FP を教えている大学さえあります。
議論で見落とされている点は、最良の型システムは現代の FP 言語にあるということです。さらに、コンパイラはすべての (または少なくともほとんどの) 型を自動的に推論できます。
Java をプログラミングするときに型名を書くのに半分の時間を費やしているのは興味深いことですが、Java ははるかに型安全ではありません。Haskell プログラムで型を書くことは決してないかもしれませんが (一種のコンパイラ チェック ドキュメントを除いて)、コードは 100% 型安全です。
それが普及するかどうかはわかりませんが、私の調査によると、関数型言語はほぼ確実に学ぶ価値があり、より優れたプログラマーになるでしょう。参照透過性を理解するだけで、多くの設計上の決定が非常に簡単になり、結果として得られるプログラムの推論がはるかに容易になります。基本的に、問題が発生した場合、何百ものクラス/メソッド/関数のいずれかによって引き起こされた可能性のある一貫性のない状態の問題ではなく、単一の関数の出力の問題である傾向があります。副作用のある命令的な言語で。
FP のステートレスな性質は、より自然に Web のステートレスな性質に対応するため、関数型言語は、よりエレガントで RESTFUL な Web アプリケーションに容易に適合します。アプリケーションの状態を維持するために VIEWSTATE や SESSION キーのようなひどく醜いハックに頼る必要がある Java や .NET フレームワークとは対照的であり、Web のような本質的にステートレスな機能プラットフォーム上で、ステートフルな命令型言語の (場合によっては非常に漏れやすい) 抽象化を維持します。
また、アプリケーションがステートレスであるほど、並列処理が容易になります。あなたのウェブサイトがたまたま人気を博した場合、ウェブにとって非常に重要です。パフォーマンスを向上させるためにサイトにハードウェアを追加することは必ずしも簡単ではありません。
最初の点には同意しますが、時代は変わります。企業は、後発であっても、利点があると判断すれば対応します。人生はダイナミックです。
彼らは 90 年代後半にスタンフォード大学で Haskell と ML を教えていました。カーネギーメロン、MIT、スタンフォード、その他の優れた学校が学生にそれを提示していると確信しています.
私は、ほとんどの「Web 上のリレーショナル データベースを公開する」アプリが、その傾向を長期間維持することに同意します。Java EE、.NET、RoR、および PHP は、この問題に対する非常に優れたソリューションをいくつか進化させてきました。
あなたは何か重要なことを思いつきました: それは、関数型プログラミングを後押しする他の手段では簡単に解決できない問題かもしれません。それは何でしょう?
大規模なマルチコア ハードウェアとクラウド コンピューティングはそれらを後押しするでしょうか?
Slava Akhmechetから、残りの私たちのための関数型プログラミングと呼ばれる素晴らしい記事があります(これは私をFPに連れて行った記事でした)。FPがもたらすメリットの中で、彼は非正統的に次のことを強調しています(これは、ソフトウェアエンジニアの魅力に貢献していると私は信じています)。
- ユニットテスト
- デバッグ
- 並行性
- ホットコードの展開
- 機械支援証明と最適化
次に、高階関数、カリー化、遅延評価、最適化、制御構造の抽象化(モナドについては説明しませんが)、無限データ構造、厳密性、継続、パターンマッチング、クロージャなど、従来から説明されているFPの側面の良さについて説明します。すぐ。
強くお勧めします !
それは実際には大学で教えられていません(またはそれは最近ですか?)
最近はわかりませんが、1990年代半ばにCSコースの一環としてミランダとLispの両方を教えられました。それ以来、純粋な関数型言語を使用していませんが、それは私が問題を解決する方法に影響を与えました。
ほとんどのアプリケーションは、通常のOOの方法で解決できるほど単純です。
同じ90年代半ばのCSコースでは、OO(Eiffelを使用して教えられた)は関数型プログラミングとほぼ同等に教えられました。当時はどちらも主流ではありませんでした。OOは現在「正常」である可能性がありますが、そうではありませんでした。
F#がFPを主流にするものであるかどうかを確認したいと思います。
いくつかの考え:
- FP と命令型プログラミング (OO、構造化など) の間の議論は、Lisp と Fortran の対決以来、激しさを増しています。あなたは素晴らしい質問をしていると思いますが、それらは特に新しいものではないことを認識しています.
- FP に対する不満の一部は、並行性が非常に難しく、オブジェクト指向 (Java など) のロックやその他のメカニズムが 1 つの解決策にすぎないことを認識しているように見えることです。FP は、アクターやステートレス コンピューティングのパワーなどのアイデアで、さわやかな海の変化をもたらします。オブジェクト指向に取り組んでいる人にとって、風景は非常に魅力的です。
- はい、学校は FP を教えています。実際、ウォータールー大学などでは初年度の授業で Scheme を提供しています (参照はこちら)。
- 平均的なプログラマーに関して言えば、1990 年代初頭に C++ に対して同じ議論がなされたことは確かです。そして、何が起こったのか見てください。 ビジネスがテクノロジーによって優位に立つことが できれば、人々がトレーニングを受けることは間違いありません。
これは、それが確かなことだと言っているわけではありませんし、3 年から 5 年以内に (いつものように) 反発がないということでもありません。ただし、FP への傾向にはメリットがあり、注目に値します。
Hackers and Painters を読んだ後、実際に LISP を学んでいます。LISP から何かを学べば、自分がプログラムしている他のすべてのことをよりよく理解できるようになると確信しています。1995 年に誰かが Yahoo ストアになった Web サイトを作成したからといって、LISP を実際に日常で使用することはないと思います。とにかく、それは双方に有利です(それがうまくいけば私は勝ちます、そうでなければ勝ちます、私はプログラミング方法と物事がどのように機能するかについてより多くの視点を得る)
さて...ちょっと関連した別の質問ですが、来年登場する32コアのプロセッサでプログラミングは大きく変わると思いますか? はい、それが関数型プログラミングになるかどうかはわかりませんが...何か違うものがあると確信しています!
他の答えに加えて、ソリューションを純粋な機能用語でキャストすると、問題をよりよく理解することができます。逆に、機能的なスタイルで考えると、問題解決能力が向上します*。
*機能パラダイムが優れているため、または追加の迎角が得られるためです。
- 平均的な企業プログラマーが OOP を理解するのにどのくらいかかりましたか?
- 私は 1994 年にユトレヒト大学で関数型プログラミングを教えられたと思いますが、それが「現実の世界で」普及し始めたのはここ数年だけです。
- 「簡単なアプリケーション」などというものはありません。;-)
ハードウェアにますます多くのコアを搭載し始めると、ソフトウェアのいくつかの重要な部分の副作用のないプログラミングに (近づく) ことが不可欠になると思います。関数型プログラミングにもう少し時間を割いてください。そして、C# の現在および将来のバージョンでの関数型スプリンクリングは、企業のプログラマーが気付かないうちに関数型プログラミングの準備を整えるのに大いに役立ちます...
関数型プログラミング言語が「次の大物」になるという最大の議論は、将来マルチコア プロセッサが標準になるということだと思います。プログラマーはそれを利用する必要があり、関数型プログラミングは、最先端の並行ソフトウェアを構築するための本当に素晴らしい可能性を提供します。
PS 私がボストン大学 ('98-'02) の大学にいたとき、LISP のいとこである Scheme の学習に 1 学期を費やしました。私たちが最初にそれを学び始めたとき、私は髪を引き裂きたいと思っていました. コースの終わりまでに、それは非常に自然でした。
あなたの質問に対する答えは、最もホットなものというよりも、「仕事に適したツール」という言葉にあると思います。常に最新の新技術があり、それに飛びつく人も常にいます。
関数型言語はしばらく前から存在していましたが、ちょうど今、より多くの報道が増えています。
個人的には、分散システムとマルチスレッド/並列プログラミングの関数型プログラミングは、間もなくブレークスルーになると思います。プログラミングライブラリを介して既存のOOPパラダイムと統合する限り。ですから...純粋関数型アプローチ-私の意見では-は学術的なままです。
Hadoopの Map/reduce ですでに普及しています
関数型プログラミングは、エンジニアや科学者が直面している問題を解決するために使用するツールになる可能性があります。以前の言語のように世界を征服するつもりはありません。ただし、打ち負かすのが難しい製品は Excel です。私がエンジニアで計算を行う必要がある場合、Excel は素晴らしいものです。
ただし、F# は別のソースになる予定であり、コンピューター科学者以外の設計ニーズを満たす可能性があります。率直に言って、コンピューター科学者は、物事を行うためのまったく新しい方法を作成するという素晴らしい仕事をしました。オブジェクト指向プログラミングは素晴らしいです。しかし、方程式を解き、解を得て、それをグラフ化する方法が必要な場合もあります。それでおしまい。次に、F# のような言語が請求書を埋めます。または、有限ステート マシンを構築したい場合、F# もソリューションの 1 つになる可能性がありますが、C もソリューションの 1 つになる可能性があります。
しかし、並列処理に関しては Excel が優れており、いずれ F# も登場するでしょう。ただし、友好的に言えば、F# はフレンドリーです。
FP は次善のパラダイムであることは間違いありません。さて、どの言語が次のステップになるか、それは難しいことですが、Haskell、F#、Clojure、Ocaml、またはErlangになると思います. または、より多くの FP コンストラクトと並列処理/パフォーマンスのより優れたサポートを備えた Python、または parrot を備えた Perl 6 が非常に興味深いものになる可能性があります。
ええと、衒学者で申し訳ありませんが、すでに普及しています - 私たちはそれを Excel と呼んでいます。
http://research.microsoft.com/en-us/um/people/simonpj/papers/excel/
コンピュータ上で実行されるプログラムの大部分は、Excel またはその多くの一般的なクローンの 1 つで記述されています。
(何度も実行されるプログラムは数多くありますが、Excel で記述されたプログラムはこれらのプログラムに該当しない傾向があります。ほとんどの Excel プログラムには実行インスタンスが 1 つあります)
多くの人が関数型言語について言及しています。
しかし、Javascript 以外に、今日使用されている最も一般的に使用されている関数型言語のいくつか。
Excel、SQL、XSLT、XQuery、J、および K は、金融分野で使用されます。
もちろんアーラン。
したがって、そのリストから、関数型プログラミングの手法が主流で毎日使用されていると言えます。
関数型プログラミングは、LISP がコンパイラを持つ最も初期の言語の 1 つであり、MIT の LISP マシン以来、長い間使用されてきました。これは新しいパラダイムではありませんが (OO ははるかに新しいものです)、主要なソフトウェア プラットフォームはアセンブリ言語に簡単に変換できる言語で記述される傾向があり、それらの API は命令型コード (C を使用する UNIX、C を使用する Windows、および Pascal を使用する Macintosh) を大いに支持しています。および後で C)。
ここ数年の新しいイノベーションは、特にプラットフォーム API が無関係な Web 開発のようなもので、多様な API がキャッチされるためのものだと思います。Win32 API や POSIX API に直接コーディングしていないので、関数型言語を自由に試すことができます。
Microsoft は、Visual Studio の次のバージョンで F# を推進しています。これは Scala などのハイブリッド言語であり、残りの .net フレームワークと非常にうまく統合されています。多くの Microsoft ショップが、高度に並列なデータ処理アプリケーションと関数の開発をスピードアップするために、これを使用すると思います。
関数型プログラミングはすでに私見にとらわれていますが、まだあまり目に見えていません。このような言語の強みは数学/アルゴリズムであり、これが Halo Guys が TrueSkill に使用する理由の 1 つです。
関数型言語が何かを解決するとは思いません。これは経営陣が売り込もうとしている誇大宣伝にすぎません。唯一の真実を覚えておいてください。
銀の弾丸はありません。
残りはすべてでたらめであり、OO が私たちの問題を解決し、Web サービスが私たちの問題を解決し、Xml が私たちの問題を解決するとも言っていましたが、最終的には上記の真実が適用され、すべてがうまくいきませんでした。また、今から 20 年後、バイナリ コンピュータを使用することになると誰が言いますか? なぜ量子コンピューターではないのですか? 少なくともこの地球上では、誰も未来を予測することはできません。(それが第二の真実です)