静的に型付けされた関数型プログラミング言語を使用する理由はありますか？

実際、ある意味では、この質問は、ほとんどの（または最も一般的な）言語が多くのパラダイムの言語である2010年代には意味がありません。 なぜ関数型プログラミングだけに制限するのですか？ おそらく答えは誰かに明白に思えるかもしれませんが、「 静的に型付けされた関数型プログラミング言語を使用しない10の理由 」などの記事が表示された場合は、厄介な視点について議論し、説明する必要があります。 「10の理由...」は皮肉に基づいており、著者は言及された欠点は議論さえ必要とせず、皮肉な発言だけが必要であることを暗示しているようです。 しかし、これはそうではありません。これらの10の理由を見てみましょう。

理由1.最新のトレンドをフォローしたくない

最もおかしい理由。 そして、実際には、なぜトレンドに従う必要があるのですか？ そしてどれ？ マルチスレッドは、2000年代の一部の人にとっては発見であり（問題自体は以前にも存在していましたが）、傾向のように思われました。 しかし、これまでに彼女に出会ったことのない人もいます。 彼らは「ファッショナブルな」（つまり、流行の）プログラマーではないからではなく、シングルユーザーアプリケーションまたはコンテナーがそれを監視するようなタスクはありませんでした。 また、Webプログラミングをサドルする時間がなく、モバイル開発をフォローする時間がありませんでした。 開発者として、すべてのトレンドをすぐに把握できますか？ あなたはできますが、あなたは選択肢があります：トップを選ぶか、1つのトピックを掘り下げます。 または真ん中にいる。 しかし、すべて同時にではありません。 おそらく、それは機能的なアプローチが非常に基本的であることを意味しており、プログラマーはそれについて知っておくべきです。 これは真実に似ていますが、トレンドには訴えません。



しかし、この傾向は非常に重要ですか？ そして、誰もが「新しいファッショナブルな言語がすぐに世界を征服するだろう」と確信できますか？ おそらくこれは誰かの啓示になるでしょうが、言語の構文やスタイルが配布や人気の基礎になることはめったにありませんでした。 おそらく60-80年代に、さまざまなスタイルのプログラミングが登場しただけでしたが、現在はそうではありませんでした。 現時点で最も一般的な（人気のある）言語のリストを調べてみましょう。



C / C ++-人気はどちらも構文に感謝するはずですが、これは遠い過去のものです。 はい、C構文により、よりコンパクトなコードを記述できます（ただし、関数型言語を支持する引数とは異なり、以前に存在していた同じ言語構成の短い表現を提供し、それらをまったく削除しませんでした）。 はい、C ++構文は、ある意味で、C上の「構文糖」であり、Cの支持者を激怒させ、C ++に対するCのパフォーマンスについて長い間議論してきました。 しかし、多くのコンパイラーはさまざまなプラットフォーム用に作成されているため、最終的にはこのペアの言語はまだ生きています。出力は実行可能ファイルであるため、パフォーマンスを第一に考える人にとっては当然の選択です。



Objective-C-人気は、Appleプラットフォームへのバインドに基づいています。



Java-C ++と比較して、ほぼ最小限の新しい構文ですが、「一度作成すれば、どこからでも開始できます」（そして、はい、機能します）。 さらに、アプレット（最終的には失敗しましたが、FlashとHTML5の先駆けでした）。 さらに、モバイル開発（非常に異なる携帯電話用の移植性のある言語が必要だったため）。 さらに、彼はサーバー側とエンタープライズにニッチを見つけました。



C＃-別のC ++クローン。すべての「砂糖」が後で登場し、有病率はWindowsへのバインドに基づいています。 モノ？ C＃で記述されたプログラムを絶対に起動するというタスクが達成されると確信していますか？ そしてこれは、.Netが独自の速度で開発されており、Monoがすべてに追いついていることを考慮しています。 さらに、多くのライブラリはWindowsと非常に密接に関係しています。



PHP / Ruby-Web開発に関連する2つの言語。 多くの人は、彼らが1つのペアになっていることを好まないでしょうが、これは人生の厳しい真実です。 ちなみに、一定数のプログラマーの間でのPHPの嫌悪は、言語の「悪い」構文によって正確に説明されています。 彼が他の関数型言語よりも人気があることを妨げないもの。 逆説的にですが、PHPは「単純な」構文とWebアプリケーションの迅速な開発のために人気を博しています。



JavaScript-Webへのリンクを備えた別の言語ですが、既にブラウザー側にあります。 また、必要に応じて-望まない場合は、ほとんどすべてのWeb開発者が精通している必要があります。 しかし、その中には「設計による」誤算があります。 そして、何も住んでいない。 さらに、最近では、彼はブラウザの外に住み始め、独立した言語になり始めました。 そして何？ なぜPythonよりも悪いのですか？



Python / Perl-もともと「スクリプト化」された（シェル言語の代替として）、Web指向の2つの言語。 しかし、Perlは次第に短くなり、時には難解な構文のために、次第に死に始めました。 考えてみてください。 何らかの構文の簡潔さの制限がまだあります。



Visual Basic-Windows / Officeプラットフォームへのバインド。



シェル-Unixへのバインド。



アセンブラ-任意のデバイスに対して最も効率的なコードを作成する機能。 繰り返しますが、多くの評価では、どの機能言語よりも人気があります。



結論は明らかです。言語は構文のおかげで普及したわけではなく、実用化されたためです。 関数型プログラミングを使用する現在の傾向は、関数型の「予期しない」発見そのものではなく、OOPの純粋主義者が言語に機能を追加しなかったという事実に基づいています。

理由2。コードの行に対して支払いを受ける

コード行の支払いを受け取った場合、管理者がパフォーマンスを正しく評価しない場合（この場合のように）に問題が発生する可能性があるため、ジョブを確実に変更する必要があります。



真剣に言えば、「コードの行」とは何ですか？ たとえば、100行のコードを含むアプリケーションがあり、それらを5行に減らしたライブラリが見つかりました。関数型プログラミングはありません。 また、同じことをして、コードを3、7、10、15、8行のコードに減らす5つのライブラリを見つけたかもしれません。 最短のものを選択する必要がありますか、それとも最高のサポート、より多くのオプション、より良いパフォーマンスなどを提供する必要がありますか？



もっと真剣に言えば、何らかの理由で、多くの人が簡潔さをコードのユニークな利点だと考えています。 はい、C、Pearl、その他の言語でそのような「美」のいやらしい例を見ました。 これらはすべてジョークやシャレードにとっては美しいものですが、長期にわたる開発にとってはそうではありません。 誰がこれを正しく読んで理解できますか？ 誰がサポートしますか？ なぜ一部の人々は、「短いコード」と「良いコード」との類似性を引き出すのですか？ ある場合もあればそうでない場合もあります。



多くの場合、コードの簡潔さと明快さは両極性の概念です。 コードが短いほど理解しにくくなり、すべてが明確に記述されているほど理解しやすくなります。 それは起こりますが、その逆も同様です。 簡潔で理解可能なコードを同時に実現できますか？ それはあなたが何を意味するかに依存します。 自然言語を見てください。 小説の意味を1つのフレーズで表現することは可能ですか？ おそらく、それはおかしくなります。 分詞ターンオーバーを動詞または他の構文で置き換えることは可能ですか？ もちろんできますが、それはスタイルの問題です-そして、あなたは常に自然言語の選択肢があります。



簡潔さはプログラミング言語に依存していますか？ サブジェクト領域の動作を記述する関数またはメソッドの呼び出しが3つある場合、それが不可能な場合、それらを1つに置き換えて置き換えることはできません。 そして、可能であれば、プログラミング言語でそれらを減らすことは問題ではありません。 そして、それはプログラミング言語の構文に本当に依存していますか？ 独自のアルゴリズムを記述する必要がある場合、この問題を解決するライブラリの存在を知らないか、ライブラリにそのようなライブラリがないか、この問題を解決する独自のライブラリを作成していません。 また、ライブラリ呼び出しは、句読点の形式のryushechokを除いて、ほとんどすべての言語で同じように見えます。

理由3.中かっこが大好き

そのような「深刻な」議論に驚いた。 この言語でかなり長い間作業している場合は、すべての括弧を自動的に配置します。多くの場合、編集者自身がこれを行います。 それでは、どのような違いがありますか？ さらに、多くの場合、1行のコードブロック（条件または反復後）でも、ブロックの境界がはっきりと見えるように中括弧を配置する必要があり、コードが間違ったブロックに挿入されたときのエラーが少なくなることを確信しています。

理由4.明示的な型が見たい

明示的な型を見るのは好きではありませんが、コンパイラが明示的な型を見るのは好きです。 私は彼に型の制御を失いたくありません。 それは多くの状況で私を守ります。 しかし、もちろん、型が暗黙的であり、すべてが何らかの形で舞台裏で機能する場合は美しいです。 しかし、美しさの代償：すべてがどのように機能するかを正確に制御できなくなります。 多くの場合、美しさの代価はパフォーマンスと暗黙の操作です。 そして、はい、メソッドが私が書いていないライブラリ、またはプログラムの他の場所で宣言された変数を含む式のタイプから返ってくるのを見たいです。 これが文字列なのかオブジェクトのリストなのか疑問に思わない。

理由5。バグを修正したい

理由6.デバッガーに住んでいる

これらはおそらく最も深刻な議論です。 これが本当なら、何百万人もの開発者がすぐに関数型言語に切り替えたいと思うでしょう。 しかし、私はこれがそうであることを疑わせてください。 なぜ関数型言語の支持者は、 こことここのバグが少ないと思うのですか。 引数は次のようになります



-ゼロなし（静的コード分析により解決）

-不変データ（すべてのプログラミング言語で利用可能ですが、特にパフォーマンスとメモリ割り当ての問題に関しては、このアプローチを常に使用できるとは限りません）

-非常に厳密な型システム（「非常に」はすでに主観的な言葉なので、この議論は著者の良心に任せます）

-小さな関数の構成（ラムダ関数は既にC＃および他の言語であり、Javaですぐになります）

-非同期プログラミングの抽象化（これは抽象化の問題にすぎず、ライブラリを使用してすべてを実行できます）

-コレクションの高階関数（C＃および他の言語で利用可能、Javaで提供されます）

-測定単位（F＃に有効、すべてのタスクに適用不可）

-操作の順序はコードで明確に表現されています（プログラミング言語で使用することは問題ではありませんが、このアプローチを使用するかどうかを選択できます）



何らかの理由で、ここでのすべてのエラーはむしろコードまたはデータのエラーになりますが、私の経験から、ほとんどのエラーは動作、ルール、オブジェクト間の相互作用に関連している可能性が高いです。 フィールド5でアルゴリズムを取得したが、3である必要がある場合、プログラミング言語の違いは何ですか？ このようなエラーは、「良い」構文ではなく、単体テストとテストによる開発で適切に処理されます。 機能的スタイルの実践者にとっては、 TDDはREPLに置き換えられますが、コードの意味が記述後に何度も変わる可能性がある場合、REPLがどのように役立つかは明らかではありませんか？



これらの議論は、ガベージコレクターを備えた言語のバグのない「美しい生活」の約束を連想させます。 はい、メモリのあいまいなバグはほとんどありませんが、概して、それらは例外ポインタ0に変わりました。 はい、メモリリークはずっと少なくなっていますが、概して、それは長寿命のアプリケーションでまだ発生しています。 もちろん、メモリ割り当てについて考えることは少なくなりましたが、まったく考える必要がないとは言えません。

理由7。すべての小さなことを考えたくない

再び感情的な議論。 これはすべて、言語ではなく開発者に依存します。

理由8. nullをチェックしたい

非常に物議を醸す議論。 掘り手が持っているアルゴリズムに従って、穴を掘るタスクがあると想像してください。 ゼロの類似点は、掘り出し人がいないことです。 そうでない場合は、はい、タスク全体を中断したいのですが、これは例外です。 まるで掘り出し人がいるかのように静かに処刑したくありませんが、穴は掘られていません。 そのような状況は関数型言語でも追跡されると言うでしょう。 しかし、すみません、それではどのような違いがありますか：ゼロまたは他の何かをチェックしていますか？ 良いことも悪いこともありますが、ゼロのチェックには時々セマンティクスがあり、単にオブジェクトの存在をチェックするだけではありません。 はい、すべてのプログラミング言語では、nullの代わりに架空の空の値（Nullオブジェクトテンプレート）を返すことができますが、実行する価値があるかどうかを慎重に検討してください。明白なエラーは暗黙的なエラーよりもキャッチしやすいです。

理由9.どこでもデザインパターンを使用している

多くの設計パターンがオブジェクト指向プログラミングの機能の結果であることは本当に秘密ですか？ そして、クロージャー、モナド、カリー化は関数型プログラミングのパターンだけではありませんか？ そして、多くの関数型プログラミングパターンがまだ先を行く可能性があります。

理由10.数学が多すぎる

これはむしろ感情的な議論でもあります。 数学は、あらゆるプログラミング言語に対応しています。 もう1つは、関数型プログラミングの美しさを証明するために、純粋な数学の例またはアルゴリズムの問​​題のみを示すことが多いことです（並べ替えアルゴリズム全体が数学に分類されるかどうかさえわかりません）。 しかし、2010年代に誰がアルゴリズムの問​​題を解決しますか？ Knutの本は40年以上前のものですが、まだソートアルゴリズムを書いていますか？ ライブラリを使用し、車輪を再発明しないでください。



モナドやファンクターが他の人が理解する上で問題になるかどうかは評価できませんが、もしそうなら、関数型プログラミングは選挙の運命であり続ける運命にあります。 これらの選択されたものを喜ばせるよりもむしろ悲しむべきもの。 これらの概念を習得できる人が少ないほど、関数型言語の可能性は低くなります。 Lispはすでに50歳であり、彼はまだ最高の時間を待っています。 また、常に選挙の継承でした。 考えてみてください。

おわりに

もちろん、機能的なスタイルには明るい未来があります。 むしろ、20年前にはなかったことは驚くべきことです。 さらに驚くべきことは、最初の関数型言語の登場から60年後にそれを言うことです。



おそらく、プログラミング言語の設計者は20年前に、概念の明確な混乱は問題に満ちているか、単に言語の「純度」を維持したいと考えていたと考えていました。 しかし、2010年代の中庭では、多くのパラダイムの言語がショーを支配しています。 そしてそれは良いことです。 概して、最初に「名詞」（OOPのように）を使用するか、「動詞」（OFのように）を使用するかは私の選択です。 オブジェクトと関数のどちらかを選択したくないので、タスクに応じてそれらを使用します。



実際、純粋な関数型プログラミングは、その「美しさ」によって多くの人を怖がらせます。 ここで、C ++、Java、C＃とは異なり、「クリーンな」OOP言語でもあるSmalltalkの歴史を思い出すと便利です。 しかし、手続き型アプローチの要素を破棄しなかった言語とは異なり、彼は決して「離陸」しませんでした。 一部には、すべてのタスクで「クリーン」なアプローチが必要なわけではなく、場合によってはまったく適用できないこともあります。 さらに、これは通常、舞台裏で暗黙的な操作を伴う抽象化の使用を意味し、通常はあまりパフォーマンスが低下する恐れがあります。 そして、実際に、論理言語（Prologなど）またはLispでのWeb開発でGUIを実装するタスクに出会った場合、「プッシュ不可能なものをプッシュする」ことの複雑さを自分で認識しなければなりません。 ただし、元の記事で言及されたF＃も多くのパラダイムの言語であり、「純粋な」関数型言語ではないことに注意してください。



おそらく、別の傾向に感心するかもしれません。JVMまたは.Netプラットフォームに基づいた多数のプログラミング言語です。 もちろん、これは任意の構文糖で書くことができますが、同じバイトコードを取得できるプラスです。 ただし、それはすべてプログラミング言語の実装に依存します-単一の呼び出しに多方向の組み合わせを使用したり、リフレクションに基づいたりすることができます。これにはパフォーマンスの問題が伴います。 また、この多様な言語が必要なのは誰ですか？ 異なる角かっこ、コンマ、コロンのみを持つ10個の関数型プログラミング言語が必要なのはなぜですか？ いいえ、本当に。



1日で新しい言語で最も簡単なプログラムを作成し、1週間で多かれ少なかれ書くことを学び、1か月で学び、1年でよく学ぶことができます。 結局のところ、問題は構文だけでなく、多くのニュアンス、「正しい」関数の「正しい」呼び出しなどにもあります。 なぜ、ある言語から別の言語にスキップするのですか？ そして、すべてのプロジェクトでどうでしょうか？ そして半年ごとに？ もちろん、これは知的挑戦です。 しかし、すべての雇用主が知的挑戦に対するあなたの内部ニーズに支払うことに同意するかどうかは疑問です。 それは雇用主の問題ではなく、あなた自身の問題でもあります-毎回、対象分野の問題と新しいプログラミング言語を入力する問題を同時に解決しなければなりません。 それに応じて、あいまいな未来が待っています（おそらく、新しい言語は将来必要になることはないでしょう）とあいまいな過去（以前の言語での経験を既に忘れている可能性があります）。 ここでも、コードサポートの問題が発生します。コードを理解している人、または最短時間で理解を習得できる人を見つける方法です。



しかし、歴史に目を向けると、バビロニアの言語群は常にそうでした。 生まれた人もいれば死にかけた人もいます。 AlgolまたはPL / 1を覚えているのは誰ですか？ しかし、他にもたくさんありました。 プログラミング言語には独自の進化があり、その中で最も強力なものが生き残ります。 そして最強のものは、美しい構文を備えた言語ではありませんが、必要な言語です。 このような関数型言語の必要性は、 ここで説明するように、開発時間の短縮とバグの数の削減に関連する可能性があります 。 ただし、上記の証拠は特定のプロジェクトが真空状態にあることに基づいているため、コードの行数が何を意味するのかは完全には不明です。 したがって、この記事のトピックに対する答えは、「はい」ではなく「いいえ」ですが、将来は私たちを判断するでしょう。