関数型言語が引用された時代がありましたが、それ以上でなくても、命令型言語と同等でした。 時間が経ち、その理由さえわかっています。 何らかの理由で、関数型言語でのプログラミングは「頭脳爆発」であると考えられています。 私は議論しませんが、時にはそれは本当に爆発的ですが、C#で他の人のソースを理解しながら定期的に経験しなければならない脳の爆発と比較して、文字通り耳に優しい拍手です。 ストーリーをスパイラルにしたい(-:
神数学言語™
どういうわけか、既存のプログラミング技術はすべて数学者によって発明されたことが人類に起こりました。 それは奇妙かもしれませんが、理解可能であり、基本的で基本的なサポートプログラミングパターンのほとんどは、手続き型または機能型です。 OOPは、大規模で複雑なシステムの作成を容易にするために発明されました。 oopを理論的に見ると、本当に、非常に便利です。 この利便性は、サードパーティのライブラリを使用する必要が生じたときに崩壊します(そして
常に発生します)。 クリエイターが善良で繊細な人々であり、あなたの神経に同情し、ユニットテストを繰り返しコードを実行し、さらにこの経済全体に論理的で理解可能な階層を提供してくれたら、とても幸せです。 そうでない場合、コードは完全に読めなくなります。 この状況での「難解なLisp」ははるかに優れています。 知っておく必要があるのは、ライブラリ関数の名前、そのパラメーター、および出力で提供されるものだけです。 このようなシステムのデバッグははるかに簡単です(
副作用がないためなど )。
言語言語の読めない難解な性質の神話は、プログラマーによるコードの認識の違いに基づいています。 命令型言語の重点は、コードの「人間の一貫した認識」にあります。 例:
int life()
{//開始
人間Peter =新しい人間(); //ペティア、生まれてください
ストレージシェルフ=新しいストレージ(); //棚、表示してください
Peter.Status = "Something good"; // Petya、よくやった
Peter.getPie(棚); //棚からパイを取り出します
0を返します。 //ここですべてが順調です、完了しました、ありがとう
} //終了
奇妙なことに、関数型言語は読みやすくなっています。 単に
プロセスではなく、
ソリューション 、結果を説明しているだけです。
たとえば、リストを切り替える関数(Erlang):
リバース(リスト)->
逆(リスト、[])。
reverse([Head | Tail]、ResultList)->
reverse(Tail、[Head | ResultList]);
リバース([]、ResultList)->
ResultList。
再帰的な性質のため、訓練されていない外観で知覚することは困難です
が、胸部を少し見ると、次の内容がプレーンテキストで書かれていることがわかります。 私は彼が好きではない、私は彼を裏返したい。 私は尾が好きです。 私はそれを自分で保持し、残りを接着して延期します。 そして、テールが突然終了した場合、リストをひっくり返して、それを捨てることができます。」
理解することは定期的に非常に難しく、実際、
アクションはどこにありますか? 私の意見では、これは定義を通じて機能するプログラムを作成できるという点で素晴らしいZenです。