Боже, временами я просто ненавижу объектно-ориентированное программирование. Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят: «Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.” Обычно я не жалуюсь, но сейчас, думаю, самое время оглянуться назад и...
На протяжении последних месяцев я использую Go для имплементаций Proof of Concept (прим.пер.: код для проверки работоспособности идеи) в свободное время, отчасти для изучения самого языка программирования. Программы сами по себе очень просты и не являются целью написания статьи, но сам опыт использования Go заслуживает того, чтобы сказать о нем...
記事の 内容は嘘！？
続きは読んでないけど。たいていの場合、筆者の戯言はすぐにコメントで指摘される。読んでみてください、全部ポイントです。
手続き型コーディングでは、プログラムを書きながら、そのアーキテクチャをカスタマイズすることがほとんど可能です。柔軟性と自由度が完全だから
+
特にトレーディングのような計算アルゴリズムでは、ただでさえOOPを忘れてしまいそうですが...。
PLOの神話について-気弱なPLO信奉者には向かない。
"OOP "については、1980年代半ばからいくつかの神話が唱えられて きました。そのひとつ、「再利用の神話」は、「OOPは、現在のコードを継承・拡張することで、もう一度書き直す必要がなく、開発の生産性を高めることができる」とするものです。もうひとつは「デザインの 神話」で、分析、設計、実装はすべて対象 であるため、互いにスムーズにつながるという意味である。もちろん、これらの神話のどれもが、OOPパラダイムになり得ない。"
そのおじさんは、学問の世界ではよくあるような理論派で、ベラベラしゃべる人です。そして、彼が教授（肩書きが屈折して久しい）であり、本の著者であることは問題ではない。
このフレーズのゴミは長い間歩き回っていて、ソフトウェア製品の指数関数的な 複雑さの増大を完全に無視しています。30年前、20年前、10年前のことは、現在のプロジェクトの規模や複雑さとは比較にならない。そして、彼らはいまだに砂場で遊ぶことを好み、模型に還元しているのです。
彼を座らせて、資源、経済性、競争力など、多くの条件を備えた本物の製品を作らせるのです。彼は、あらゆる方法で失敗しながら、瞬時にその理屈で翻意する。もっと言えば、ソリューション設計の段階で幼稚なキャプテンシーを発揮して追い出される可能性すらある。
これまで多くの銀の弾丸が試されたが、どれも無価値であることが証明され、長い間見放されてきた。それは、複雑さの一定の成長、ライブラリの成長（そしてopがある）、フレームショット（そしてopがある）を残して、少なくとも複雑さのいくつかの制御を可能にします。
そして、複雑化していることから逃れることはできません。さらに複雑化し、知識の質の要求についていけない無教養な開発者が増えるだろう。
今後、ますます減少するプログラマーの大衆化に合わせて、さらにシンプルな言語を開発する試みが行われるでしょう。間違った技術を信じるだけで、競争競争に敗れ、不利になるソフトウエア会社がますます増えていくだろう。ただ、競合他社はもっと重くても、製品の成果として有効な技術を使ってくるはずです。
ソフトウェア会社への投資は、昔から命がけです。死亡率や故障率は驚異的で、これからもっとひどくなる。
なぜ？そう、技術ではなく、経済的な要求が大量にあるビジネスだからです。生きているソフトウェア会社の約80％は、マーケティングとセールスで構成されています。間違った技術（ここで多くの人は、想定されるシンプルさを優先する）は、将来の売上を簡単に減少させるのです。なぜなら、より困難な道を歩んで、最終的に良い結果を得たライバルが必ず存在するからです。
さて、10万行までのマイクロプロジェクトについてです。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。もし、それをスケールアップしようとしたら--痛み、挫折、そして死。
結論
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
PLOについて語る
レナート・ファットフーリン さん 2018.01.17 09:17
おじさんは、学問の世界ではよくあるような理論派で、ベラベラしゃべる人です。そして、彼が教授（この肩書きは長い間、膨張してきた）であり、本の著者であることは問題ではない。
このような言い回しで作られたゴミは長い間出回っており、ソフトウェアの複雑さが指数関数的に増大することを完全に無視しています。30年前、20年前、10年前のことは、現在のプロジェクトの規模や複雑さとは比較にならない。そして、彼らはいまだに砂場で遊ぶことを好み、模型に還元しているのです。
彼を座らせて、資源、経済性、競争力など、多くの条件を備えた本物の製品を作らせるのです。彼は途端に理屈をこねて手のひらを返し、あらゆる方法で失敗していくだろう。もっと言えば、ソリューション設計の段階で幼稚なキャプテンシーを発揮して追い出される可能性すらある。
これまで多くの銀の弾丸が試されたが、どれも無価値であることが証明され、長い間見放されてきた。それは、複雑さの一定の成長、ライブラリの成長（そしてopがある）、フレームショット（そしてopがある）を残して、少なくとも複雑さのいくつかの制御を可能にします。
そして、複雑化していることから逃れることはできません。さらに複雑化し、知識の質の要求についていけない無教養な開発者が増えるだろう。
今後、ますます減少するプログラマーの大衆化に合わせて、さらにシンプルな言語を開発する試みが行われるでしょう。間違った技術を信じたばかりに、競争競争に敗れ、不利な立場に立たされるソフトウエア会社がますます増えていくだろう。ただ、競合他社はもっと重くても、製品の成果として有効な技術を使ってくるはずです。
ソフトウェア会社への投資は、昔から命がけです。死亡率や故障率は驚異的で、これからもっとひどくなる。
なぜ？そう、技術ではなく、経済的な要求が大量にあるビジネスだからです。生きているソフトウェア会社の約80％は、マーケティングとセールスで構成されています。間違った技術（ここで多くの人は、想定されるシンプルさを優先する）は、将来の売上を簡単に減少させるのです。なぜなら、より困難な道を歩んで、最終的に良い結果を得たライバルが必ず存在するからです。
さて、10万行までのマイクロプロジェクトについてです。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。もし、それをスケールアップしようとしたら--痛み、挫折、そして死。
結論
今月、いや、今年一番の記事です。レナートさん、なぜあなたやあなたの会社はhubraに記事を書かないのですか（会社はhubraに登録すらしていない！）？言いたいことはたくさんあるのに、あなたの経験はあなたの投稿から断片的にしか学べないのです。真面目な話、非常に話題性があり、正確です。あなたの投稿を説明するために、https://habrahabr.ru/post/344356/。
今月、いや、今年一番の記事です。
OOPの話題の中で、この投稿のどこがそんなに気に入ったのでしょうか？商業的なものも一般化するのはちょっと違うかもしれません。投資家も馬鹿ではないので、専門家を交えてプロジェクトの リスクを評価するわけですが......。
一部の、それでも教授によるこの記事は、具体的な論理的主張があり、それに対する十分な反論が提示されていないため、議論にならない...。
また、単純なポグラフィが必ずしもプロジェクトにとって悪ではないことも明らかで......。
今月、いや、今年一番の記事です。レナートさん、なぜあなたやあなたの会社はhubraに記事を書かないのですか（会社はhubraに登録すらしていない！）？言いたいことはたくさんあるのに、あなたの経験はあなたの投稿から断片的にしか学べないのです。真面目な話、非常に話題性があり、正確です。投稿への図解としてhttps://habrahabr.ru/post/344356/
私たちは、Habraの記事で通常得られる1,000～5,000人の読者/視聴者ではなく、数百万人を対象に仕事をしています。
業界標準を作り、世界にインパクトを与えるソリューションをリリースしています。なぜ、ハーブルのようなものが必要なのか、しかもロシア人という狭いニッチな層に詰め込んで。
OOPの話題の中で、この記事のどこがそんなに気に入ったのでしょうか？商業的なものも一般化するのはちょっと違うかもしれません。投資家も馬鹿ではないので、専門家を交えてプロジェクトのリスクを評価するわけですが......。
この記事には、一部の、それでも教授による具体的な論理的主張があり、それに対する十分な反論が提示されていないため、議論に...
また、単純なポグラフィが必ずしもプロジェクトにとって悪ではないことも明らかで...。
ディレッタントなジブンはやめてください。
単に技術的な知識がないために禁止されるだけです。好戦的な無知な人は、このフォーラムには必要ありません。
...
また、プログラミングがシンプルであることが、プロジェクトにとって必ずしも悪ではないことも明らかです...。
複雑なものはどこにも 行かないという公理があります。その結果、ユーザーにとっての「プログラミングの簡便さ」は、コンパイラへの複雑さの転嫁となる。その複雑さは、あたかもコンパイラが裏で処理しているかのようであり、コンパイラは、「何もしないよりは、何とか動くようにした方が良い」という原則に従って、プログラマーの曲解を隠そうとする。プログラマーではなく、コンパイラーがプロジェクトのオーナーになる。何が起こっているのか理解できないので、コードの開発やメンテナンスが不可能になる（コンパイラは何とか構築しているが、ともかく）。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
OOPについて語る
レナート・ファットフーリン さん 2018.01.17 09:17
...
そして、複雑化の一途をたどっていることから逃れることはできません。さらに複雑化し、知識の質の要求についていけない文盲の開発者が増えるだろう。
今後、プログラマーの大衆化に合わせて、よりシンプルな言語を開発する試みはさらに進んでいくだろう。間違った技術を信じたばかりに不利な立場に立たされ、競争競争に敗れるソフトウエア会社が増えるだろう。ただ、競合他社は、重くても製品の成果という点ではより効果的な技術を使ってくるでしょう
...
ディレッタントなジブンはやめてください。
単に技術的な知識がないために禁止されるだけです。私たちのフォーラムに過激な無知な人たちは必要ありません。