関数型プログラミングはコードを複雑にしますか？[閉まっている]

過去1年間、私はScalaコードを書いてきました（Javaのバックグラウンドから来ています）。vals、caseクラス、map / filter / lambda関数、暗黙的および型推論を使用して、よりシンプルでクリーンなコードを作成できる方法が本当に気に入りました。主にAkkaベースのアプリケーションに使用しました。

今年は、関数型プログラミングが大好きな新しいチームとScalaプロジェクトに参加しています。それらはScalazを頻繁に使用し、コードはあらゆる場所にapplicatives、context bounds、reader / writer / stateモナドで満たされ、メインメソッドもI / Oモナドに「ラップ」されます。彼らの推論は、これによりコンパイラがコードが正しいことを主張する際に「私たちのために働く」ようにし、各関数に副作用がないことです。

それでも、私の観点からすると、この構文はすべてビジネスロジックの邪魔になります。たとえば、「MyBusinessObject」のタイプは問題ありません。「List [MyBusinessObject]」、「Option [MyBusinessObject]」、「Future [MyBusinessObject]」などのタイプも同様です。それらはすべて明確な意味と目的を持っています。一方、次のようなコード：

def method[M[_]: Applicative] = {
  case (a, b) => (ca[M](a) |@| cb[M](b)) {
    case t @ (ra, rb) =>
      if (ra.result && rb.result) t.right
      else t.left
  }
}

それはプログラムに複雑さを追加しますか、それとも私がこのプログラミング方法に慣れていないのは私だけですか？

これは関数型プログラミングとは何の関係もありません -他のプログラミング言語のコンテキストでこの種の状況を見つけることができます-「彼らの」言語の高度なコンストラクトを愛する開発者は、読みやすさと物事をシンプルに保つという常識を無視します。C、C ++、Perl、Java、C＃、Basic、およびその他の非機能言語でこのような状況に遭遇しました。コードを複雑にするのは関数型プログラミングではありません-プログラマーはそうします。

誤解しないでください。高度な言語機能を避けることはお勧めしませんが、与えられたコンテキストで適切なバランスを見つけることが重要です。世界中で100,000人を超える開発者が使用する汎用ライブラリを作成する場合、ローカルオフィス専用の個別のレポートジェネレーターを作成する場合とは異なる方法が適用されます。

私はあなたが彼らのコードのやり方に慣れていないことは少なくとも絵の一部だと言うでしょう。私はあなたと同じような状況にあります（C＃からF＃に来て、Haskellのバックグラウンドを持つ人々と一緒に仕事をしています）、それは面白い経験ですが、壁に頭をぶつけて、もつれを解く瞬間があります特に複雑な点のない関数合成は、そこで何が起こっているのかを把握するためです。それは文化的なものです。

この特定のコードがプログラムに複雑さを追加するかどうかについて-私は知りません。コードの一般的な部分自体が複雑になる可能性があることに同意しました。ただし、これはユーティリティであり、ビジネスロジックの一部ではありません。コードベースをより複雑にするのか単純にするのかを知りたい場合は、そのコードなしでどのように見えるかを想像する必要があります。多くの場合、それら自体が複雑であるような一般的な構成体の場合ですが、単一の画面に収まる複雑さです。同時に、コードベース全体をかなり簡単にします。これは特にモナドの場合です。

また、@ Doc Brownが示唆するように、「芸術のための芸術」の場合もあります。除外することもできません。

一般に、関数型プログラミングは可変状態を排除することで複雑さを軽減し、コードのセクションがどのように機能するかを理解しようとするときに考慮しなければならないケースの数を減らすと主張します。

ただし、関数型プログラミングにより高度な抽象化が可能になり、高度に抽象化されたコードは非常に便利ですが、定義によって通常は理解を導くために使用するコンテキストとは離婚しているため、理解することも困難です。ビジネスオブジェクトについての「それらはすべて明確な意味と目的を持っています」というコメントは間違いなく真実ですが、そのロジックは既に理解しているニーズとコンテキストに非常に特有であるという事実を反映しています。Monadのような構造の存在により、ほとんど労力をかけずに非常に便利なものを作成できますが、WebにはMonadとは何かを説明しようとするページが散らばっています。それはあなたのための抽象化です。

また、Scalazは長い間FPを食べて呼吸していた人々によって書かれました。彼らはHaskellで利用可能な機能をScalaに持ち込みたかったのです。そうすることで、彼らは教育的であろうとはしなかった。Scalazは、著者にとっては明確で分かりやすいように見えますが、初心者には馴染みのない語彙とスタイルを使用しています。Haskellのバックグラウンドを考えると、私たちの残りの人にとって困惑している方法は、著者にとって非常に明白であるように思われたため、コメントすら正当ではありませんでした。

さらに、関数型プログラミング言語として、Scalaにはいくつかの欠点があり（一部にはJVMに欠点があるため）、Scalazの作者にforcedいコードを書くことを強制する場合がありました。たとえば、一般的なテールコールの除去がないため、一部のコードでトランポリンの使用が強制され、「種類のシステム」がないために型シグネチャが複雑になる可能性があります。

そして最後に、Scalazはそれ自体を大いに活用しています。それはその力のしるしと考えることもできますが、初心者にとってはソースをパズルにすることができます-あなたが見ているコードのランダムな部分は、あなたにとって異質のものを利用する可能性があります。

頑張れ。そして、これは役立つかもしれません。

それはプログラムに複雑さを追加しますか、それともあなたがこのプログラミング方法に慣れていないというだけですか？

なぜこれらの可能性は同じではないと思いますか？

よく書かれたコードは、特定のプログラミング言語に精通していない人でも読むことができます。一部の言語（BASIC、Pascalなど）は、プログラミング言語を見たこともない小学生でも読んで理解することができます。

他の言語の経験とScalaの経験がある人（そして少なくとも1週間はScalazと仕事をしていて、トリッキーなことを説明する同僚がいる人）がまだ混乱している場合; それはそれが複雑さを追加したという証拠です。