関数型プログラミング：JavaとCの式が多すぎる＃

多くの人が関数型プログラミングについて聞いたことがある人もいれば、独自のHello Worldを作成しようとした人もいれば、独自の「機能的な」ペットプロジェクトを開始した人もいました。 しかし、実稼働で使用されている関数型言語の数は？ AFの長所と短所は何ですか？ 関数型プログラミングのパラダイムは、開発者の期待に応えていますか？ 20年間のOOP開発の後、機能的アプローチの利点を発見した人が、これらの質問や他の多くの質問に答えることができました。







Vagif Abilovは、ノルウェーの会社Milesの開発者です。 速度とスケーリングに高い要求を課す実際のプロジェクトで関数型プログラミングを積極的に使用します。

OOPでは、事前に狭いフレームワークで作業するように強制します。

-Vagif、手続き型およびオブジェクト指向の後に関数型プログラミングに来ましたか？ それとも機能的な最初のものでしたか？ あなたの出発点は何でしたか？



Vagif Abilov：関数型プログラミングに目を向け始めたとき、オブジェクト指向プログラミングで約20年の経験がありました。 90年代にはC ++でしたが、.NETの登場により、C＃でプログラミングしました。 私は典型的なバックエンド開発者です。 彼はサービスに携わり、主にスケーラビリティと速度が重要なプロジェクトに携わりました。



私が他の何かを詳しく調べ始めた主な理由の1つは強調できます。 このようなシステムがOOPを使用してどのように記述されているかを見ると、いわゆる共有状態または共有状態は大きな問題です。 つまり、マルチスレッドシステムを使用している場合は、共有データにアクセスできる必要があります。 したがって、フローを手動で管理する必要があります。誤って壊れないように共有状態を閉じる必要があります。 これを正しくプログラムするためだけに、人的資源の大部分が費やされます。 一般的に、これは主要な機能である主要な主題領域の一部ではありません。



付随する要因の1つは、「 アムダルの法則 」として定式化されたものであり、並列処理のリソースの可用性に対する並列システム速度の依存性を確立します。 具体的な例では、次のように聞こえます。「10個のプロセッサを搭載しているが、40％しか並列化しない場合、パフォーマンスは1.56倍に向上します。」 したがって、さまざまなストリームからのデータへのアクセスを制限することに重点が置かれているシステムを並列化する可能性はあまりありません。 これはある時点で私に合わなくなり、私は共有状態を取り除くことができるような方法でそれを解決する機会をもっと見始めました。 多くの関数型言語の利点は、それらがデフォルトで変異しないこと、正確に変更できないことです。 これが関数型プログラミングに目を向け始めた最初の理由でした。



約6年前、私はかなり大規模な国際会議NDCで講演する招待状を受け取りました。 その時までに、私はすでにFPで趣味のプロジェクトに取り組み始め、そこでF＃の経験を発表していました。 主にC＃開発者が関数型プログラミングのレポートに来て、喜んで聞いてから、次のように尋ねたロマンチックな時期でした。 それを適用することさえ可能ですか？」 多くの場合、スピーカー自体は、実際のシステムではFPを使用しないが、収集されると述べました。 私はほぼ同じ状態でした。つまり、C＃のすべてのプロジェクトで働いていましたが、楽しみのためにF＃に精通しました。



私のレポートは、「機能的なConwayの人生のゲームをプレイする」、つまり、関数プログラミングの方法によるConwayのゲーム「Life」の実装と呼ばれていました。 有名なゲーム。 私はF＃でそれを書く方法を示し、それを実行し、それを理解し始めて、私は驚いた。 その前に、CodeProjectのC＃でこのゲームを実装するプロジェクトを見つけたと言わなければなりません。 このプロジェクトは5つのクラス、5つのプロパティとメソッドで構成され、300行を超えるコードがありましたが、効果的でした。 すべてのブラケットを削除しても、約100行が残っています。 Life＃でF＃を書いたとき、14行の実行可能コードを取得しました。平均2行に7つの関数があります（これが制限だと思う場合は、F＃でのConwayのゲームのソリューションに適した140文字の英語プログラマーPhil Trelfoldのコードを見てください twitterに投稿されています）。 F＃の開発のコンパクトさが衝撃を受けました。 これは私が感銘を受けた最初のものです。 その後、コードのレビューを始めました。 私は考え始めましたが、このコードは一般的に二次元ボードのために決定されたと言っていますか？ セルの近傍を計算する1つの関数だけが2Dボードであることを示していることがわかりました。 この機能が3次元または多次元のボードで動作するように置き換えられた場合、すべてが機能します。



多くの関数型言語、特にF＃には、いわゆる型推論があります。データの型を直接指定しない場合、コンパイラは、使用方法に応じて、何を置き換えるかを決定します。 これにより、すぐに一般化されたコードを記述できます。 JavaまたはC＃でクラスを一般化する必要がある場合、F＃ではデフォルトでこれが発生します。 これには非常に大きな利点があり、さまざまなプロジェクトに取り組んで個人的に確認することができました。



最終的にレポートを準備し、会議で彼と話したとき、私は聴衆に目を向けて、Conwayのゲームをどこから書き始めたらよいか尋ねました。 ほとんどすべてがクラスとプロパティの定義で提案されました。たとえば、クラス「Board」、「Cell」を入力し、「Cell」のプロパティを定義する必要があります。 つまり、誰もが型とその関係の定義から始めることに慣れています。 私たちはとても慣れています。 しかし、実際には、このような多数の定義を事前に導入すると、それらの定義をさらに処理する上で大きな制限が課せられます。 F＃で「Life」ゲームを実装する際の3番目の重要な側面は、そこにタイプを導入しなかったことです。 すべては機能を設定することによって行われました。 これにより、ソースデータを「再生」する方法に完全な自由が与えられます。 OOPでは、私たちが導入した定義の枠組みの中で事前に作業することを「強制」することに気付きました。



私はレポートのプレゼンテーションで作業していたときに、この状況を説明するのに適したツイートを見つけました。 英語を話すプログラマーは次のように書いています。「 Javaでのプログラミングはロシア文学をやるようなものです 。 イベントが発生する前に100個の名前を定義する必要があります 。 」 このコメントは、OOPアプローチを適切に定義しています。 最初にすべてを適切に説明する必要があります。そうすると、いくつかのイベントが発生し始め、定義にいくつかのメソッドを「ストリング化」できるようになります。 そして、しばしば、私たちのデザインはすでに私たちを制限しています。



元の質問に戻りますが、関数型プログラミングの世界での出発点となったのは、データの変更から逃れるための試みだったと言わなければなりません。

JavaとCには「式」が多すぎます＃

-あなたの意見では、オブジェクト指向プログラミングに長い間従事している人は、機能を知り、機能に切り替えるべきですか？



Vagif Abilov：完全な移行の問題は、実際的な問題です。 そして、知り合いになるために、もちろんそうです。



JavaやC＃のようなオブジェクト指向言語を見ると、近年非常に大きな変化が生じています。 混乱しない場合、C＃バージョン3.0でLINQが登場し、ラムダ式が登場したとき、これは既に関数型プログラミング要素の導入に向けた顕著な動きでした。



「関数型言語の要素を使ってC＃で多くのことができるのに、なぜ関数型言語自体を研究すべきなのか」という議論が生じます。 C＃とJavaの両方が常に変異言語のままであるため、これに対する少なくとも1つの答えは、データ構造の可変性の分野に入ります。 デフォルトで定義するデータを変更できる場合、関数型プログラミングのどの要素を入力しても、これらの言語の基本的な本質は変わりません。 C＃の最新バージョンでは、FPの要素を「再生」できますが、もちろん、 Erlang 、 Haskel 、 F＃などの実際の関数型言語で作業することは理にかなっています。 この言語は.NETに非常によく統合されるため、特に後者をお勧めします。 いくつかの例を解析するだけで十分です。コードがどれほど簡潔かを確認してください。 これは、私の意見では、コードのコンパクトさという重大な議論です。 プログラマーが経験を積むほど、JavaやC＃などの言語には「式」が多すぎることに気づくはずです。 通常、F＃のプログラムはC＃の2倍のコンパクトさであるため、コードを半分に減らすと、それらを回避できます。



-OOPと比較したAFの利点は何ですか？



Vagif Abilov：最初に言ったように、データの突然変異はありません。これは非常に重要です。 関数型言語で書かれたプログラムには変数がありません。 ある意味では、彼らはすぐに「タフ」であることが判明します。



オブジェクト指向のコードを見ると、いくつかの変数とデータがあり、それらはどこかに送信され、すべては多くのスレッドからアクセスされます。 関数型言語では、最初は少し混乱します。変数を導入せずに、どのように動作させることができますか？ しかし、すべては「機能変換」の方法を使用して実現されます。 これがまさに並列処理の基礎を作成するものです。 データを受け取ったら、「スレッドセーフかスレッドセーフか？」という質問に答える必要はありません。 これは、多くのスレッドからのアクセスを生き延びますか？」 定義により、何が生き残るかを知っています。 多くのスレッドからのアクセスを確認するためにテストを行う必要さえありません。



変数が不足しており、機能変換によってすべてをスキップするという事実により、テストは大幅に簡素化されます。 結果として、論理エラーはコンパイラにより頻繁にキャッチされます。 F＃で作業するときの「良い」問題の1つは次のとおりです。プログラムをコンパイルするためだけに数時間費やすことができますが、これが発生するとエラーなしで機能します。 あまりにも「だまされやすい」ので、テストの記述を少なくします。 最初に私はこれと戦おうとし、C＃と同じ数のテストを書きました。 そして、ほとんどの論理エラーはコンパイラーによってキャッチされるため、これは必要ではないことに気付きました。これは、オブジェクト指向言語のコンパイラーよりも「寛容」ではありません。



おそらく、これらが主な利点です：並列性、突然変異の欠如、論理エラーの影響を受けやすいコンパイラとのより大きな相互作用。 また、ワークスタイルも変化しています。 C＃で作業する場合、私はよく古典的なTDD方法論を使用します。 F＃では、REPLモードで動作します（読み取り-評価-印刷ループ）。 このような作業は非常に効果的です。



-OOPと比較してAFの力を超えるものはありますか？ 彼（FP）の欠陥は何ですか？



Vagif Abilov：各タスクには、独自の資金を使用する必要があります。 スケーラブルなシステムを高速で開発する際の関数型言語の利点については、これは理解でき、よく知られています。 しかし、私にとっては、ビジュアルインターフェイスを操作するときの関数型プログラミングの利点は明らかではありません。 プログラムがシングルスレッドであり、フォームを編集する場合は、一般に、フォームがデータモデルに適合しやすいため、オブジェクト指向のアプローチを使用するのが自然です。 F＃、Clojure、Erlangもユーザーインターフェイスの開発に使用されますが、その利点は私には明らかではありません。



また、関数型言語を使用すると、開発者は並行性とパフォーマンスの問題を自分で解決することを決定できますが、これはパフォーマンスに影響する問題の分析に置き換わるものではありません。 たとえば、開発者がマルチコアプロセッサを使用している場合、これについて考える必要があります。 プログラムは、プロセッサキャッシュを利用するように作成する必要があります。 キャッシュは常に更新されるため、パフォーマンスが低下する可能性があります。 これは、一般的に言えば、関数型プログラミングやオブジェクト指向プログラミングとは何の関係もないタスクです。 いずれにせよ、高速でスケーラブルなプロジェクトを開発する場合、それらが動作するシステムの内部アーキテクチャを理解する必要があります。 言い換えれば、これは「特効薬」ではなく、関数型言語に対処することでこれらすべての問題がすぐに解決されるとは期待できません。



-要約すると、FPはどのタスクに焦点を当てていますか？



Vagif Abilov：並列性、高速を必要とする問題を解決します。 一般に、バックエンド全体を関数型言語で正常に記述することができます。



-Vagif、FP言語でプロジェクトを実装するには、どのインフラストラクチャ（ツール）を収集する必要がありますか？



Vagif Abilov：私はC＃とF＃で作業しているので、私にとってVisual Studioは最もよく使用されるツールです。 しかし、より多くの場合、私は他の、より「重い」手段を使用することに気付きます。 たとえば、F＃言語に関して、.NET開発、つまりIonideプラグインを使用したVisual Studio Codeについて話している場合。 これはF＃で作業するための素晴らしい環境です。



Atom + Ionide、VS Code + Ionide、Paket、Fakeなどのエディターを使用することをお勧めします。 テストには、F＃に適したフレームワークがあります。FsUnitとExpectoライブラリは、関数型言語と非常によく統合されます。 そして先日、まだベータ版である新しいJetBrains Rider IDEがF＃をサポートするという情報がありました。 JetBrainsは一般的に実用的な男であり、F＃のサポートについて尋ねられたときに反抗し、Resharperプラットフォームに言語の原則を埋め込む複雑さで動機付けたため、これは注目に値するイベントです（私が理解するように、オブジェクト指向言語には存在しないタイプの実装に関連する困難） しかし、氷は壊れており、F＃は.NET環境で非常に重要な言語になっているため、さらに無視することができます。



Webアプリケーションを作成する必要がある場合は、すばらしいSuaveフレームワークがあります。 WebアプリケーションまたはWebサービスをほんの数行で非常にコンパクトに記述できます。 マイクロサービスの実装について話すと、非常に機能的な言語がアクターモデル（アクターモデル）と連携して機能します。 過去1年半の間、このモデルが実装されているAkka.Netを使用してF＃でシステムを開発しています。



特に、F＃で実装され、データベースを非常に効率的に使用できるタイププロバイダーは重要なコンポーネントになります。 Entity Frameworkのような重いライブラリを置き換えます。



ところで、興味深い例です。 F＃オープンソースにはSQLProviderライブラリがあります。これは、MSSQL、Oracle、SQLite、PostgreSQL、MySQL、MsAccess、ODBCという1つのモジュールに一度に7つのドライバーが含まれるという点で異常です。 そして、このすべての重さはわずか1.3メガバイトです。 また、各データベースのドライバーは約600〜800行のコードです。 ちなみに、これはF＃で多くのことを書くことができるということです。



-個人アカウントで関数型プログラミングを使用して実装された大規模で深刻なプロジェクトはありますか？



Vagif Abilov：はい。 Akka.Netの助けを借りて、過去1年半にわたってF＃の小さなグループで、速度とスケーリングの要件が高いシステムを作成してきました。 このシステムは、ノルウェーの州のラジオテレビ向けに開発されています。 彼女は数百テラバイトのファイルを操作し、クラウドを操作しています。 システムの複雑さにもかかわらず、コードは非常にコンパクトです。



-あなたの意見では、AFはOOPと競争するほど人気が​​出るでしょうか？



Vagif Abilov：競争に関しては、すでに関数型プログラミングがオブジェクト指向とうまく競合しており、多くのプロジェクトでそれを置き換えています。 定量的比較について話す場合、どのような時間の観点について話しているのかを理解する必要があります。 おそらく、今後5年間で、FIはさまざまな理由でOOPを備えたプロジェクトに匹敵する数に達することはないでしょう。 その1つは、オブジェクト指向言語を使用すると、プログラミングの学習を始めるのがはるかに簡単になることです。 さらに、ユーザーインターフェイスを備えた多数のタスクがありますが、FPの利点は明らかではありません。



大規模でスケーラブルなシステムは、関数型言語でますます記述されるように思われます。 この理由の1つは、ムーアの法則が機能しなくなることです。 より早い段階で、より強力なプロセッサが登場するのを待つことができれば、すべてが自動的に高速になりますが、今はできません。 アーキテクチャが増加しないことを認識し、念頭に置いて、アーキテクチャを既存の速度に戻す必要があります。 これは、関数型プログラミングを支持する非常に大きな切り札です。



-関数型プログラミングの学習を開始することを決めた人に何をアドバイスできますか？



Vagif Abilov：この選択を深刻な人生のステップとして扱わないようにアドバイスします。 プログラマーのメイン言語を変更しようとすると、たとえばデータベースや何らかのフレームワークを変更するのとは異なり、ある種の急進的なステップと見なされることに気付きました。 たとえば、javascript開発者は、手袋のように使用するライブラリを変更します。 そして、これは何らかの大きな変化のようには見えません。 リレーショナルデータベースからドキュメントデータベースに切り替えた場合、これは1つの.NET言語から別の言語に切り替えるよりもはるかに深刻な手順です。



私はかつて、F＃の顧客の1人のためにシステムを作成した人たちと話す機会がありました。 F＃でプロジェクトを行うことを顧客に納得させるのはどれほど簡単かを尋ねました。 彼らは、顧客はこれについて知らされていないと言った。 システムが.NETの下で動作するように、契約書に書かれています。 実際、このアプローチには何かがあります。 このオペレーティング環境向けに作成している場合、私のアドバイスは、できる限り多くのことを試してみることです。 他の言語、ライブラリ、プログラミングモデルを試してください。 これはすべて良いことです。



-5月に開催されるDotNextサンクトペテルブルク会議でのレポートはどうなりますか？



Vagif Abilov： 私の現在の報告は関数型プログラミングに直接関係するものではありませんが、ある意味ではパラダイムシフトに関連しています。 型付きプログラミングを好む人と動的型でプログラミングを使用する人の両方が等しく簡単に使用できるように、開発者がAPIを作成する方法について説明します。 ご存知のように、.NET 4.0の登場により、C＃に動的型を組み込むことが可能になりました（動的型）。 ある意味では、パラダイムシフトに備える必要があると言います。 これにより、今日の会話のトピックに関連するレポートが作成されます。



5月20日にサンクトペテルブルクで開催されるDotNextカンファレンスで講演するVagif Abilovによるレポートのトピック全体は、 Typed APIまたは動的APIのように聞こえますか？ 両方！ このイベントでお会いできることをうれしく思います。世界各地から、そして最も関連性のあるトピックについて、約30人の素晴らしいスピーカーを集めました。