私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト 全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなAOPにも役立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働投入量としては、コーディング自体が20％程度でした。
私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなOOPでも役に立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働集約度では、コーディング自体が労働投入量の20％程度を占めていました。
私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなOOPでも役に立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働集約度では、コーディング自体が労働投入量の20％程度を占めていました。
このようなシングルタイプのタスクで、OOPがなければやらない方が良い例を教えてください。
OOPがなくても解けるけど、OOPがあったほうが早いって、言ったでしょ...。
例えば、1つのパターンは0から100のローソク足パターン、0から30の異なる指標、そしてそれぞれ1から5の異なるシグナルを含むことができます...つまり、1つのクラスがあり、最初のインスタンスには23のパターンと1つのシグナルを持つ2つのインジケータが含まれるとコンストラクタで設定することができます...。2番目のインスタンスには、他の12のパターンと他の8つのインジケータが含まれます...そして、両方のインスタンスが互いに4小節以上離れないように開くシグナルを出すという条件を設定した・・・。
このようなことは、パターン信号やその他すべてが授業で説明されていれば5秒で終わるのですが...。そして、このすべての組み合わせはいくらでもあり、お客様がいなくても、オプティマイザーで自動的にすべてを最適化し、有利な入力条件を探すだけ...。オプティマイザは、インスタンスとそれぞれのプロパティの数を拡大することができます...まあ、などなど))
これは本論ではありません。
手続き型プログラミングにはポリモーフィズムの 類型はありません。
不思議なことに、私はプログラミングの全くの素人で、今でもある程度はプログラミングの練習をしていますが、ポリモーフィズムを使う必要性を感じたことはありません...。それが私の運命なのでしょう。
(地獄の沙汰も金次第...))
OOPがなくても解けるけど、OOPがあったほうが早いって、言ったでしょ...。
例えば、1つのパターンに0～100個のローソク足パターン、0～30種類のインジケーター、そしてそれぞれに1～5種類のシグナルが含まれることがあります...。つまり、1つのクラスがあり、最初のインスタンスには23のパターンと1つのシグナルを持つ2つのインジケータが含まれるとコンストラクタで設定することができます...。2番目のインスタンスには、他の12のパターンと他の8つのインジケータが含まれます...そして、両方のインスタンスが互いに4小節以上離れないように開くシグナルを出すという条件を設定した・・・。
このようなことは、パターン信号やその他すべてが授業で説明されていれば5秒で終わるのですが...。そして、このすべての組み合わせはいくらでもあり、お客様がいなくても、オプティマイザーで自動的にすべてを最適化し、有利な入力条件を探すだけ...。オプティマイザは、インスタンスの数やそれぞれのプロパティを拡大することができる......など ))
今回のGOPの騒動は、世界的な規模で起きています。
やはり、これだけの才能がないと、このようなものを世界中に押し出すことはできないでしょう。
そして、謝罪者たちを止めるものは何もありません。
ローカルアポータを取れば。そんな彼らの目の前にあるのが、MQL言語のハンドブックだ。セクションを見てみましょう。データに関する部分は3つだけで、あとはプログラム、配列操作、データ変換......といったアクションを記述しています。
もしかして、これは「最先端の考え」に適合しないμl言語なのでしょうか？
もっと大きなソフトウェアシステムであるRを例にとってみましょう。
1万を超えるパッケージがあり、それぞれが関数を含んでいる。これらはオブジェクトではなくアクションである。
つまり、データの価値（セマンティクス）は関数であり、そのデータを処理するアクション である、ということです。彼らはintを書いた。これらの文字の意味は、この変数でACTIONを実行する方法を知っているプロセッサコマンドのセットで決定されます。
次に、クラスについてです。
Rを例にとると、どのクラスが言語の一部であるかについて。
関数は、あるクラスのオブジェクトを入力し、通常は別のクラスのオブジェクトを出力します。入出力フィールドの意味は、それをすべて処理する関数によってのみ決定される。また、この関数があるクラスを受け入れない場合、このクラスはこの関数にとって何の役にも立たない。そのため、各パッケージのドキュメントはµlのものと全く同じで、アクションと関数が記載されています。また、あるパッケージの関数間、あるいは別のパッケージの関数とのリンクは、その関数が扱うクラスの名前によって決定される。
もう一度。Rでは、オブジェクトは任意の複雑さを持つことができ、実際に非常に複雑にすることができます。しかし、あるクラスのオブジェクトの各フィールドの値は、そのオブジェクトを生成する関数によってすべて決定される。
特に、コンパイラを書く人（私がそうでした）にとっては、これは明白なことです。ある一連のコードが書かれている。このコードは何をするものなのでしょうか？このコードの意味は何ですか？どんなプログラミング言語でも、ソース言語のテキストの意味は、コンパイラが作成する実行コードによって決まり、最終的にはプロセッサによって知覚されることになる。ある言語のコンパイラは、書かれた行の意味を見出すが、別の言語では見出せない、つまり、書かれた行はこの別の言語では意味を持たないのである。
したがって、オブジェクトの意味は、常に関数であり、入力データを行動の指針として受け取り、あるフィールドのリストを出力することができる行動であり、その値はこの関数によってのみ決定されるのである。
コノフが上で説明しようとしたのは、「ACTIONS（行動）」から入るということだ。アクションを扱う必要があり、そのアクションをつなぐオブジェクトは、後でアクションを定義するときに扱います。しかし、コードの明快さと効率性は、純粋にアクションの階層全体とその相互作用をいかにうまく整理できたかによってもたらされます。
OOPの推進者は、「オブジェクトを作ろう」と言います。しかし、フィールドに対するアクションを定義しないのであれば、オブジェクト・フィールドの意味は何なのでしょうか？
パターンが含まれているパターンは、どのように実装されていますか？関数なのか配列なのか、それとも別のものなのか？パターンそのものはどのように書かれているのですか？
そうですね、普通に描写されていますね。
別の例では...クラスは本のある図書館のようなもので、コピーはトロッコのようなもの...。トロリーに図書館から好きな本を載せて...。...そしてもっと儲かるものを探す...）図書館や1台のトロッコはOOPでなくてもできますし、大量のトロッコの話になるとOOPでやった方がいい...となります。
これは、私が現在認めている、開発におけるOOPを支持する唯一の論拠です。
受け入れてはいけないのです。
私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト 全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなAOPにも役立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働投入量としては、コーディング自体が20％程度でした。
OOPの擁護者の意見に耳を貸してはいけない。あなたは正しい道を歩んでいます。2つの変数を1つの構造に統合しないことでさえ、利益を表示しない
もうひとつ、最もシンプルな例として、ごく表面にあるのは......。MetaEditorのEAジェネレータ...プログラミングができなくても、膨大な数のインジケータとコンディションを含むEAを10秒で組み立てることができる )))そして、これらはすべてOOPである )))
ジェネレーターの話はやめよう、2ヶ月間悪口を言わないと決めたから )))
MQ開発者の同志たち、私はあなたたちを尊敬しています。本気です。
そして、このようなコンストラクターが作られた理由も理解できます。また、このようなコンストラクターがすべて屁の河童になってしまう理由も理解できます。
確かに、MQL5を勉強するための一種の例として見ることはできますが、決して本物の取引ロボットの出発点として見るわけではありません。
受け入れてはいけないのです。
私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなOOPでも役に立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働集約度では、コーディング自体が労働投入量の20％程度を占めていました。
OOPの擁護者の意見に耳を貸してはいけない。あなたは正しい道を歩んでいます。2つの変数を1つの構造に統合しないことでさえ、あまり利益を生み出さない
サンサンヒ、最近、プロゲイザーと呼ばれる人から連絡があり、マーケットで何か売ることまでできたそうです。
あるプログラムを糊付けしようとしたらコンパイルエラーになったので、言ってみれば糊を送ったということだ。彼はお金を払うと約束した。
見てみたけど、コンパイルエラーが59個もあって気持ち悪い。
n,c,mなどのグローバル変数 がたくさんある。
すべて相反するものです。
そして、この男は、少し手を加えるだけで、マーケットに投げ込むことができると確信している。
...
私の理解では、ローカルやグローバルな起源を持つOOPの弁明者たちは、プログラミングの何も理解していない。つまり、あらゆるデータの価値（セマンティクス）は、このデータを処理する関数、アクション であるということだ。彼らはintを書いた。これらの文字の意味は、この変数に対してACTIONを実行する方法を知っているプロセッサコマンドのセットによって決定されます。
...
きおくに
受け入れてはいけないのです。
私が最後に所属していたチームは300人ほどでした。プログラムプロジェクト全体の作業量は、約1500人年です。そのようなチームを組織して一緒に仕事をすることは、どんなOOPでも役に立ちません。そのためには、問題全体を段階的に分解し、各段階において、あらゆるものを、あらゆる人に注意深く規制していくという方法があった。それを記述したGOSTがあった。プログラミングでは、USSD（Unified System of Program Documentation）である。労働集約度では、コーディング自体が労働投入量の20％程度を占めていました。
OOPの擁護者の意見に耳を貸してはいけない。あなたは正しい道を歩んでいます。2つの変数を1つの構造に統合しないことでさえ、利益を表示しない
このようなプログラムは、今では1人で3日もあれば書けるようになりました。