PLOについての興味深い見解

 
過激なFP活動家の記事を少なくする。FPのコンセプトは1年や2年ではありません。でも、革命が起きたという話は聞きませんね
 

これはOOPの問題ではなく、その応用、さらに言えば応用する側の問題です。彼らが感じるのは...

OOPの助けを借りて、信じられないような文章を書くことができることに熱狂し、恍惚としているのです。

信じられないほど複雑なコード(そして、その中で競争することさえも)。彼らは自分たちを特別なエリートだと感じている。

さらに、自分たちの「偉大な本」を発明し、それを読んでも読んでも

が、読めないのです。デザイン パターン」と呼ばれるもので、人間の言葉で言うと

は、「ファジーでマズくて混乱するコードを書く究極の技術」と訳されています。しかし、もし

とてもクールなものです。

は、生活を簡素化し、シンプルにします。

 

このような記事は、FPに不慣れな人が書いている可能性が高く、20個のタブがあるような分かりにくいフックになっている...と理解すべきです。

ハードFPは別格として、OOPの饒舌さ、便利さ、機能をあらかじめ宣言できることなど、いろいろなことを考えさせられますね......。要するに、一方と他方が似ていること。それはちょうどそのような記事は、多くの場合、手続き型コードのみを習得した人々によって書かれている - そしてこれはFPに近いものでもないので、あなたがフックとその鮮やかな使用を知らない場合は、FPは論外でありません

また、記事にある「死にゆく言語」の多くは、FPとOOPの全機能をサポートしています。 そして、そのうちのいくつかは、CISで 最も高い報酬を得ています。
 
私はむしろ、FPで「溺れる」ということを考えずに、OOPで「スパゲティ化」するという話をしていました。私の考えでは、手続き的なパラダイムは、OOPよりも現実的で資源効率に優れていると思います。
 
Mikhail Mishanin:
FPに「溺れる」なんてことは全く考えず、むしろOOPで「スパゲティ化」しているのです。私の考えでは、手続き的なパラダイムは、OOPよりも現実的で資源効率に優れていると思います。

ただ、OOPの方がコード自体が長いということですか? まあ、そうですね、コンストラクタがあるので、場合によってはその方がコードが長くなるのが普通ですが......。技術的にはFP展開の方がマシンコード生成の効率は良いはずなのですが...。が、コードがシンプルにならないし、タイピングに関しても普通のラッパーを作るのは無理だし......。

最近は混在していることが多いので、互いに干渉しあうことはない。

 
Alexandr Andreev:

ただ、OOPの方がコード自体が長いということですか? まあ、そうですね、コンストラクタがあるので、場合によってはその方がコードが長くなるのが普通ですが......。技術的にはFP展開の方がマシンコード生成の効率は良いはずなのですが...。が、コードがシンプルにならないし、タイピングに関しても普通のラッパーを作るのは無理だし......。

現在では、どちらか一方ともう一方が混在していることもよくあります。

OOPとFPがなければ、すべてが簡単で速く動きますが(そう、「美点」やパネルなどがなければ)、自分のコードでさえ理解するのが難しいことがあります)。

 
Mikhail Mishanin:

OOPとFPがなければ、すべてが簡単かつ迅速に動作しますが(そう、「美点」やパネルなどがなければ)、自分のコードでさえ理解するのが難しいことがあります)。

まずはどちらか、あるいは両方をマスターして、どちらがいいかを判断してください。そして、今のようなやり方では、やがて自分の理解できないこと(つまりほとんどすべて)に賛成するフェドセーエフになってしまうでしょう。

 
世界的な新技術のトレンドは、新しいものを3ヶ月研究し、1ヶ月使って(バグをたくさん集めて)廃棄し、また新しいものを3ヶ月研究し、1ヶ月で廃棄する(またバグをたくさん集めて)、というものである。こんな生き方が好きな人がいたら、それはそれで歓迎です。
 

なんという破壊的な話題への反応と破壊的な議論でしょうか。手続き型プログラミングの信奉者である私に、OOPにおける「スパゲティ化」を回避する方法、パース方法、他人の「スパゲティ」を使うことに意味があるかどうかを教えてください。

結局のところ、OOPは読みやすさとチームプログラミングのため、つまり大規模なプロジェクトのためにあることがほとんどなのです。アカウント内のバランス/資金の最大リスクの制御とそのチャートにシンボルを取引Expert Advisorは、よく、大きなプロジェクトを呼び出すことはできません - それはメモリ/速度で十分かつより収益性の高いです - 手続き上のプログラミングを。

質問です。

- 個人的な経験から見たOOP(命令形)の欠点/長所

- FPのデメリット/長所(宣言的なものとして)個人的な経験から。

また、展望についての意見は、特に並列コンピューティングの 方向で、もちろん興味深いものです。量子の話題に触れても意味がないと思うのですが。

 
Mikhail Mishanin:

手続き型プログラマとして、OOPにおける「スパゲッティ化」を回避する方法を教えてください。

決定論的な関数を書くように努力する、というのが引用した記事にあるレシピです。

分解方法と、他人の「スパゲッティ」を使うことに意味があるのか?

確かに良いコードですが、スパゲッティではありません。

結局のところ、何が得られるかというと、OOPは主に可読性とチームプログラミングのため、つまり大きなプロジェクトのためのものなのです。

そうですね。

残高や口座資金を最大限にリスクコントロールしながら、シンボルをチャートに貼り付けて取引するEAは、まあ大きなプロジェクトとは言えませんので、手続き型プログラミングで十分ですし、メモリやスピードの面でもより収益性が高いです。

オーストラリアに行くには飛行機を使った方が便利(OOP)、近隣の都市に行くには車や自転車でも十分(PP)です。目的を達成するために、より便利な手段を選べばいいのです。