そこでの議論のほとんどは、指から吸い取られるようなものです。OOPの無効性を「証明」する実験もあるが、まったく正しくない。通常のOOP言語では、sum(int a, int b)は、内部でa += bのように無意味なことを書いても、常にクリーンです。繰り返しになりますが、オブジェクトがメソッド内部でヒープ上に確保された場合、それを呼び出したメソッドのみがそのオブジェクトへの参照を持っているので、常に保護されています。自由に変更することができます。参照用と重要用とがある。OOP言語で副作用のないクリーンな関数を書くことを妨げる人はいない。数学の標準的な関数は、例えばこんな感じです。確かに共有リソースがないとどうしようもないこともありますが、便利なスレッドセーフコレクションなどがあります。結局のところ、どんな純粋なFPであっても、IO、BD、ネットワークリクエスト、その他多くのものと必然的に相互作用することになり、そこで修正可能デーモンが突破口を開くことになるのです。
なんという破壊的な話題への反応と破壊的な議論でしょうか。手続き型プログラミングの信奉者である私に、OOPにおける「スパゲティ化」を回避する方法、パース方法、他人の「スパゲティ」を使うことに意味があるかどうかを教えてください。
結局のところ、OOPは読みやすさとチームプログラミングのため、つまり大規模なプロジェクトのためにあることがほとんどなのです。アカウント内のバランス/資金の最大リスクの制御とそのチャートにシンボルを取引Expert Advisorは、よく、大きなプロジェクトを呼び出すことはできません - それはメモリ/速度で十分かつより収益性の高いです - 手続き上のプログラミングを。
質問です。
- 個人的な経験から見たOOP(命令形)の欠点/長所
- FPのデメリット/長所（宣言的なものとして）個人的な経験から。
また、展望についての意見は、特に並列コンピューティングの 方向で、もちろん興味深いものです。量子の話題に触れても意味がないと思うのですが。
どこから来たのか確認したいのですが、スパゲティーのことが全くわかりません。
どのようなコードでも、関数はできるだけ短くするのが良い特徴です。もっとあったほうがいいんじゃない？
例えば、OOPのプロパティの半分は、ユーザビリティのために分けたいものです。例えば、いくつかの関数をグループに分け、それぞれの名前空間に住むような変数を与えるなどです）。
ストレージタイプの「クラス」を使っているので、すべての変数に特定のタイプを与えるように明確に事前定義することができる......というわけです。
は、外部APIを作成するのが便利です。作業時にクラスリファレンス（8バイト）で作業できる - 非常によく使われる。
例リンクされたノードリストとかいろいろ。
// ここでは、私が見た特殊性だけを書きましたが、protectedメソッドの可能性やプロパティなど、書いても意味がないことは明らかです...。というのは、ただの砂糖です。
FPのプロパティは、どこかで、何かの後に、例えば、関数-現在の関数を分割して、現在の関数の変数のいくつかを使って、その場で新しい関数を作りたいような場合に行うものです。その実行を別の関数に渡すには、まだ起きていない計算を遅延させた関数を渡すだけでいいことがわかった......ただのコードの断片として。
実はこれ、かなり便利なんです。
これは、実際にはどのような関数があるのかが明確に分かるため、フルコードのアンロールという特性が残ります。これは、OOPよりも計算が速くなる可能性が高いのです。また、関数が過去の関数から呼び出された変数の環境を完全に記憶しているので、非常にクールです（実際には、宣言された変数を外部スコープから保存しているだけですが）。一方、FPは、関数の アドレスを設定して、クラスのように配列に格納することができます - 特に便利ではありませんが。
遅延動作、各種非同期関数、並列計算のコードを簡単に書くことができる
引用された論文と決定論の概念そのものをもとに、私の懸念を説明しよう。スパゲティ化」で怖いのは（コード自体の複雑さと計算ミスを 見つける作業）？この記事では、変数の値が「ゴミ」であることや、関数の戻り値が非決定的であることに着目しているのです。
自分の変数（進化）構造のニューラルネットワークを構築・訓練する。そして、彼らにとっては、価値観の中の「ゴミ」がどこからともなく出てくることが非常に重要なのです。
記事のように、ブレーキペダルを踏んでも、ペダルはあなたのことなど気にもしていません。それは使用中です。また、ニューラルネットワークの構築（アーキテクチャの自動選択）と学習の初期段階で「ゴミ」が可能だとしたら、それはどのように構築／学習されるのでしょうか？
OOPで "ゴミ"（非決定性）を極力避けるには？
引用された論文と決定論の概念そのものをもとに、私の懸念を説明しよう。スパゲティ化」で怖いのは（コード自体の複雑さと計算ミスを 見つける作業）？では、この記事で強調されているのは何かというと、変数に「ゴミのような」値を入れること、関数から非決定的な値を返すこと、です。
自分の変数（進化）構造のニューラルネットワークを構築・訓練する。そして、彼らにとっては、価値観の中の「ゴミ」がどこからともなく出てくることが非常に重要なのです。
記事のように、ブレーキペダルを踏んでも、ペダルはあなたのことなど気にもしていません。それは使用中です。また、ニューラルネットワークの構築（アーキテクチャの自動選択）と学習の初期段階で「ゴミ」が可能だとしたら、それはどのように構築／学習されるのでしょうか？
OOPで "ゴミ"（非決定性）を極力避けるには？
この記事は、明らかにconst変数の型を指定するのを忘れています。その後、サイズを変えてはいけない（定数でなければならない）オブジェクトが、なぜか定数でないときにエラーが発生したらしい・・・と書いており、これに基づいて、OOPではエラーが発生する確率が高いという結論を出しています))) 。
一般に、OOPでは変数の領域を制御することができます。OOPは、関数から変数を渡すように設計されています。つまり、変数はほとんどない可能性が高いので、デフォルトですでに定義されているはずです。また、必要であれば、この機能自体をその場で拡張することも可能です。
すなわち、OOPでは、より多くの初期制御がある
それだ、いつも疑っていたんだ)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23私は、誰がこのような「記事」を書くのか、空虚なレトリック、一般的なフレーズ、最小限のセンスを理解できません。
「トヨタのダメなプログラマーのせいで、OOPではコードが混乱 すると考えることにします。
"組み込みのOOP機能は混乱を招くだけ だ。「C#の機能が増え続ければ、単純なコードを書くことは不可能になります。はい。
「つまり、プログラムの異なる部分が同じデータ構造を扱うことができ、それを変更 することもできるのです。これでは、プログラムがグローバルな状態の大きな塊になってしまい、OOPの本来の考えと矛盾して しまいます」 - そして、プライベート、プロテクト？
「この引用が気に入らないとしたら、それは一般に非決定論はどこにも行き 着かないからだ。"そうですね、予測不可能な関数GetMicrosecondCount、MathRand、CoptBuffer、すべてのネットワーク関数、その他は、結果が外部状態に依存するので、捨て去るべきです。恐ろしいことです。
もういい、ここですべてが明らかになった。
ほら、いつも疑われる)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23そこでの議論のほとんどは、指から吸い取られるようなものです。OOPの無効性を「証明」する実験もあるが、まったく正しくない。通常のOOP言語では、sum(int a, int b)は、内部でa += bのように無意味なことを書いても、常にクリーンです。繰り返しになりますが、オブジェクトがメソッド内部でヒープ上に確保された場合、それを呼び出したメソッドのみがそのオブジェクトへの参照を持っているので、常に保護されています。自由に変更することができます。参照用と重要用とがある。OOP言語で副作用のないクリーンな関数を書くことを妨げる人はいない。数学の標準的な関数は、例えばこんな感じです。確かに共有リソースがないとどうしようもないこともありますが、便利なスレッドセーフコレクションなどがあります。結局のところ、どんな純粋なFPであっても、IO、BD、ネットワークリクエスト、その他多くのものと必然的に相互作用することになり、そこで修正可能デーモンが突破口を開くことになるのです。
変な記事だな...。
量から質に変わる傾向があります。
無線機がたくさんあると、電磁波の相性が悪くなり、動かなくなることがある。
コードのスパゲッティ特性は、通常、量からくるもので、異なる状態で多くの用途がある場合、ラッパーのすべての特性を考慮していない。
機能的にはフィードバックの存在が同じことをもたらすでしょう。ヒステリシスはジョークです)
問題を理解し、正しく理解する ...))))
// ここでは目に見える機能しか書いていないので、明らかにprotectedメソッドの可能性や特性など書いても意味がないのですが...。というのは、ただの砂糖です。
FPのプロパティは、私たちがどこかで、何かの後に、例えば、関数でその場で新しい関数を構成したい - 現在のものを共有し、それは私たちの関数から現在の変数のいくつかを使用します。その実行を別の関数に渡すには、まだ起きていない計算を遅延させた関数を渡すだけでいいことがわかった......ただのコードの断片として。
実際、かなり便利です。
さて、OOPで同じことをするのを防ぐ人はいるのでしょうか？純粋な手続き型言語でも？ある関数へのポインタを別の関数に渡すと、遅延実行される。
一般に、非同期は純粋なデザイン パターンである。純粋なC言語でも非同期コードを書くことは可能です。タスクを部分的に実行するステートマシンを作ればいいのです。ちなみに、計算されるのに時間がかかるMQLのインジケーターでやりました。チャートの速度が遅くならないようにするためと、達成率が変化するステータスバーをきれいに表示するために行いました。
では、OOPで同じことができないようにする人はいますか？純粋な手続き型言語でも？ある関数へのポインタを別の関数に渡して、遅延実行を実現するのです。
一般に、非同期は純粋なデザインパターンである。純粋なC言語でも非同期コードを書くことは可能です。タスクを部分的に実行するステートマシンを作ればいいのです。ちなみに、計算されるのに時間がかかるMQLのインジケーターでやりました。チャートの速度が遅くならないように、また、実装率が変化するステータスバーをきれいに表示するのに役立ちます。
) また、アセンブラを使用することもできます。問題は、どこが簡単かです。
そして、私をどちらか一方に入れないでください...。どちらかにこだわるわけではないんです。
不思議な記事です。なぜなら、手続き型スタイルでは、デフォルトですべてを手続き型スタイルで行うことができ、その逆でもひどいコードの肥大化は起きないからです。つまり、OOPは「上部構造の上」であって、根本的に異なるスタイルではないのです。
もし、この記事が本当に手続き的ではなく、機能的なものであるなら(これは摘発してもそれほど明らかではありませんが)、なぜ全く用途の異なるものを比較するのでしょう。
トピーカスターター、あなた自身が書いて今話しているのは、機能的か手続き的か、どちらでしょうか？
結局のところ、OOPは可読性とチームプログラミングのため、つまり大きなプロジェクトのためにあることがほとんどだということがわかりました。
OOPの使い方がわからない。でも、プリミティブなものは使っていますよ。先日から、とてもシンプルな コードを掲載しています。
最終的に何を見る必要があるのか理解できていない状態で、FPで書き始めたこと。
OOPの原始的な要素を通して完成させた。おそらくFPのスキルは失われていますが、ここではOOPの方がずっとシンプルで読みやすいように思えました。
コードは非常にシンプルで短いものです（説明）。FPで書けば、比較できて面白いかもしれませんね。