ラウンジでPLOについて語る - ページ 21 1...14151617181920212223 新しいコメント Nikolai Semko 2018.01.17 11:24 #201 Nikolai Semko: 軍事的な無知 - なんて的確で簡潔なんだ。語彙を増やそう:)) なんと、この言葉は私の敬愛するエレーナ・イヴァノヴナとコンスタンチン・ニコラエヴィッチ・ローリチが使っていたことが判明したのだ。この世界では何も変わらない...。 Georgiy Merts 2018.01.17 11:33 #202 Andrei:いや、論点が違う。番組のロジックで食べなければならないバナナがあるのですが、ヤシや黒土も一緒に食べなければなりません。そうですね、違いますね。ヤシの木も、黒い土も、肥料も、サルも、すべて封じ込められたもので、そこにアクセスすることはできません。 そういうことです。それは、機能的なアプローチにあります。バナナを手に入れるためには、すべてのエクストレイルを後ろに引きずらなければならないのです。OOPアプローチでは、コンパイラがそれを引きずってくれます。あなたは-合意されたインターフェースを通じて「バナナ」を入手し、それがどこから来たのかわからない。ちゃんとしたアクセス権があれば調べられる。 それがOOPのポイントです。必要なもの、この場合はバナナだけが利用できるようにすればいいのです。パーム肥料-ピーナッツはありません。存在する（そうでなければ、バナナはどこから来たのか）。しかし、あなたはそれにアクセスすることはできないし、どんなに意志を持ってしても、ヤシの木を切り倒したり、あなたのバナナを引き裂いているまさにそのサルを殺したりはできないだろう。 Georgiy Merts 2018.01.17 11:44 #203 Andrei:普通の人にとっての苦悩は、マゾヒストにとっての喜び...。:) 普通の人がナイフを使って制限するのは、苦行なのでしょうか？普通の人が交通ルールで自分を制限するのは、苦行なのでしょうか？ Nikolai Semko 2018.01.17 11:58 #204 引用された2つの論文の著者は、間違ったことに人生を費やしてしまった、深い不幸な人たちだと思います。これは、残念ながら、よくあることです。プログラマーではなく、ライターであるべきだったのです。明らかに、気に入らない作品は、OOPを攻撃することで表現していたのです。純粋に人間的に理解することができるのでしょう :))結局のところ、OOPパラダイムを真に理解できるのは、自分の技術に惚れ込んだ本物のプログラマーだけなのです。 Petros Shatakhtsyan 2018.01.17 12:12 #205 PLOが自分の家であり、自分のルールがある、というイメージでしょうか。すべてに共通することがあります。こちらはテーブルチェア、フォーク、スプーンなどです。しかし、この家の住人にさえ、手に入らないものがあるのです。例えば、身の回り品、金庫など。金庫の所有者は、金庫へのアクセスを与えることができます。他人が勝手にこの家に入る権利はない。この家、何があるのか、それぞれの機能を クラスで表現することができます。 そして、家そのものがオブジェクトなのです。OOPは私たちの人生と同じです。人のように見え、それを記述し制御する魂と、物体である肉体の2つの部分から構成されています。OOPは規律であって、アナーキーではない、誰が何をやってもいいということです。 Georgiy Merts 2018.01.17 12:17 #206 Nikolai Semko: 結局のところ、OOPパラダイムを真に理解できるのは、自分の技術に惚れ込んだ本物のプログラマーだけなのです。必ずしもそうではありません。前ページのRenatは、「彼に実際のプロジェクトを やらせたら失敗する」と、至極もっともな指摘をしています。そして、その人はすぐに、すべての欠点を補って余りある、OOPのすべての利点を確信するようになるでしょう。ここでOOPを批判している人たちは、たとえ小さな複雑なプロジェクトであっても、一度も執筆に参加したことがないのではないでしょうか。というのが彼らの意見です。車は間接資源を大量に必要とするから逃げられない、その鉄くずの山をずっと持ち歩かなければならない、つまり歩いた方がよっぽど正しい」みたいなね。そして実際、隣の通りへ行くのはかなり愚かなことです。しかし、他の町に行かなければならない場合--「歩く」ことについて真剣に語る人はほとんどいない。 そして、それはここでも同じです。 Nikolai Semko 2018.01.17 12:32 #207 George Merts:必ずしもそうではありません。前ページのRenatは、「彼に実際のプロジェクトをやらせたら失敗する」と、至極もっともな指摘をしています。そして、その人はすぐに、すべての欠点を補って余りある、OOPのすべての利点を確信するようになるでしょう。ここでOOPを批判している人たちは、たとえ小さな複雑なプロジェクトであっても、一度も執筆に参加したことがないのではないでしょうか。というのが彼らの意見です。車は間接資源を大量に必要とするから逃げられない、その鉄くずの山をずっと持ち歩かなければならない、つまり歩いた方がよっぽど正しい」みたいなね。そして実際、隣の通りへ行くのはかなり愚かなことです。しかし、他の町に行かなければならない場合--「歩く」ことについて真剣に語る人はほとんどいない。 そして、それはここでも同じです。 そういうことなんだ...。 fxsaber 2018.01.17 13:29 #208 Renat Fatkhullin:今、十万行までのマイクロプロジェクトに。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。それをスケールアップしようとすると-痛み、挫折、死が待っている。10Kラインのプロジェクトでも、OOPなしは考えられませんね。おそらく、ほとんどいないのではないでしょうか。 Vladimir Pastushak 2018.01.17 13:38 #209 Renat Fatkhullin:そのおじさんは、学問の世界ではよくあるような理論派で、ベラベラしゃべる人です。そして、彼が教授（肩書きが屈折して久しい）であり、本の著者であることは問題ではない。このフレーズのゴミは長い間歩き回っていて、ソフトウェア製品の指数関数的な複雑さの増加を完全に無視しています。30年前、20年前、10年前のことは、現在のプロジェクトの規模や複雑さとは比較にならない。そして、彼らはいまだに砂場で遊ぶことを好み、模型に還元しているのです。彼を座らせて、資源、経済性、競争力など、多くの条件を備えた本物の製品を作らせるのです。彼は途端に理屈をこねて手のひらを返し、あらゆる方法で失敗していくだろう。もっと言えば、ソリューション設計の段階で幼稚なキャプテンシーを発揮して追い出される可能性すらある。これまで多くの銀の弾丸が試されたが、どれも無価値であることが証明され、長い間見放されてきた。それは、複雑さの一定の成長、ライブラリの成長（そしてopがある）、フレームショット（そしてopがある）を残して、少なくとも複雑さのいくつかの制御を可能にします。そして、複雑化していることから逃れることはできません。さらに複雑化し、知識の質の要求についていけない無教養な開発者が増えるだろう。今後、ますます減少するプログラマーの大衆化に合わせて、さらにシンプルな言語を開発する試みが行われるでしょう。間違った技術を信じたばかりに、競争競争に敗れ、不利な立場に立たされるソフトウエア会社がますます増えていくだろう。ただ、競合他社はもっと重くても、製品の成果として有効な技術を使ってくるはずです。ソフトウェア会社への投資は、昔から命がけです。死亡率や故障率は驚異的で、これからもっとひどくなる。なぜ？そう、技術ではなく、経済的な要求が大量にあるビジネスだからです。生きているソフトウェア会社の約80％は、マーケティングとセールスで構成されています。間違った技術（ここで多くの人は、想定されるシンプルさを優先する）は、将来の売上を簡単に減少させるのです。なぜなら、より困難な道を歩んで、最終的に良い結果を得たライバルが必ず存在するからです。さて、10万行までのマイクロプロジェクトについてです。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。もし、それをスケールアップしようとしたら--痛み、挫折、そして死。結論プロジェクトの複雑性は増しており、今後も増え続ける。多くの新しいアイデアやアプローチは、結果を出すことなく死んでいくでしょう。ほとんどのソフトウェアがオープンソースで書かれており、今後もそうなるであろう。ソフトウェアベンチャー企業への投資は、失敗率が高まる。出口はなく、痛みと苦しみがあるだけです。すべては言葉だけの良さ、美しさ...。OOPを使って大規模で面白いプロジェクトを 作るには、その方法を知ることが必要です。1 - 方法を知っている人は、ここでµlに行かない、言語はいくつかのプラットフォームに限られており、彼らはすでにビジネスのプロ（他の言語でのプロジェクトを持っている）である...。2 - そして、その方法を知らない者は、OOPなどを猿のように捻じ曲げ、何も生み出さないだろう...。そう、もちろん、金融市場のファンも少なからずいるが、本格的に何かをして、人生を切り開くには少なすぎる......。主な関心事は...つまり、Renat、mt 5はもうすぐ10年になる、10年なんて冗談じゃない...ということです。そして、OOPプログラミングの適切なトレーニングがない...。私が書いたトピックは何ですか？OOPについて、そしてその結論は？ゴミの中へ...。レナートさんに質問なんですが、μlで大きなプロジェクトをプログラムする人は、どこでどのように登場すればいいのでしょうか？ fxsaber 2018.01.17 13:56 #210 Vladimir Pastushak:μlで 大規模なプログラミングをする人は、どこからどのように出てくればいいのでしょうか？これまでも、そしてこれからも、言語やプラットフォームに関係なく、一つの取引所内でアルゴトレーディングの大きなプロジェクトが 行われることはないでしょう。せいぜい半自動化されたプロジェクトがあるくらいです。 どんな言語でもいいから、セミオートマで大きなプロジェクトを1つでも？スケルパードライブが一番大変です。しかし、決して大衆受けするものではありません。また、質量がないのであれば、なぜわざわざ大きなものを作るのか？片膝をついてマーケット向けのものを作る方が簡単です。 1...14151617181920212223 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
軍事的な無知 - なんて的確で簡潔なんだ。語彙を増やそう:))
いや、論点が違う。番組のロジックで食べなければならないバナナがあるのですが、ヤシや黒土も一緒に食べなければなりません。
そうですね、違いますね。
ヤシの木も、黒い土も、肥料も、サルも、すべて封じ込められたもので、そこにアクセスすることはできません。
そういうことです。それは、機能的なアプローチにあります。バナナを手に入れるためには、すべてのエクストレイルを後ろに引きずらなければならないのです。OOPアプローチでは、コンパイラがそれを引きずってくれます。あなたは-合意されたインターフェースを通じて「バナナ」を入手し、それがどこから来たのかわからない。ちゃんとしたアクセス権があれば調べられる。
それがOOPのポイントです。必要なもの、この場合はバナナだけが利用できるようにすればいいのです。パーム肥料-ピーナッツはありません。存在する（そうでなければ、バナナはどこから来たのか）。しかし、あなたはそれにアクセスすることはできないし、どんなに意志を持ってしても、ヤシの木を切り倒したり、あなたのバナナを引き裂いているまさにそのサルを殺したりはできないだろう。
普通の人にとっての苦悩は、マゾヒストにとっての喜び...。:)
PLOが自分の家であり、自分のルールがある、というイメージでしょうか。すべてに共通することがあります。こちらはテーブルチェア、フォーク、スプーンなどです。しかし、この家の住人にさえ、手に入らないものがあるのです。例えば、身の回り品、金庫など。
金庫の所有者は、金庫へのアクセスを与えることができます。他人が勝手にこの家に入る権利はない。
この家、何があるのか、それぞれの機能を クラスで表現することができます。 そして、家そのものがオブジェクトなのです。
OOPは私たちの人生と同じです。人のように見え、それを記述し制御する魂と、物体である肉体の2つの部分から構成されています。
OOPは規律であって、アナーキーではない、誰が何をやってもいいということです。
結局のところ、OOPパラダイムを真に理解できるのは、自分の技術に惚れ込んだ本物のプログラマーだけなのです。
必ずしもそうではありません。
前ページのRenatは、「彼に実際のプロジェクトを やらせたら失敗する」と、至極もっともな指摘をしています。そして、その人はすぐに、すべての欠点を補って余りある、OOPのすべての利点を確信するようになるでしょう。ここでOOPを批判している人たちは、たとえ小さな複雑なプロジェクトであっても、一度も執筆に参加したことがないのではないでしょうか。というのが彼らの意見です。
車は間接資源を大量に必要とするから逃げられない、その鉄くずの山をずっと持ち歩かなければならない、つまり歩いた方がよっぽど正しい」みたいなね。そして実際、隣の通りへ行くのはかなり愚かなことです。しかし、他の町に行かなければならない場合--「歩く」ことについて真剣に語る人はほとんどいない。
そして、それはここでも同じです。
必ずしもそうではありません。
前ページのRenatは、「彼に実際のプロジェクトをやらせたら失敗する」と、至極もっともな指摘をしています。そして、その人はすぐに、すべての欠点を補って余りある、OOPのすべての利点を確信するようになるでしょう。ここでOOPを批判している人たちは、たとえ小さな複雑なプロジェクトであっても、一度も執筆に参加したことがないのではないでしょうか。というのが彼らの意見です。
車は間接資源を大量に必要とするから逃げられない、その鉄くずの山をずっと持ち歩かなければならない、つまり歩いた方がよっぽど正しい」みたいなね。そして実際、隣の通りへ行くのはかなり愚かなことです。しかし、他の町に行かなければならない場合--「歩く」ことについて真剣に語る人はほとんどいない。
そして、それはここでも同じです。
今、十万行までのマイクロプロジェクトに。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。それをスケールアップしようとすると-痛み、挫折、死が待っている。
10Kラインのプロジェクトでも、OOPなしは考えられませんね。おそらく、ほとんどいないのではないでしょうか。
そのおじさんは、学問の世界ではよくあるような理論派で、ベラベラしゃべる人です。そして、彼が教授（肩書きが屈折して久しい）であり、本の著者であることは問題ではない。
このフレーズのゴミは長い間歩き回っていて、ソフトウェア製品の指数関数的な複雑さの増加を完全に無視しています。30年前、20年前、10年前のことは、現在のプロジェクトの規模や複雑さとは比較にならない。そして、彼らはいまだに砂場で遊ぶことを好み、模型に還元しているのです。
彼を座らせて、資源、経済性、競争力など、多くの条件を備えた本物の製品を作らせるのです。彼は途端に理屈をこねて手のひらを返し、あらゆる方法で失敗していくだろう。もっと言えば、ソリューション設計の段階で幼稚なキャプテンシーを発揮して追い出される可能性すらある。
これまで多くの銀の弾丸が試されたが、どれも無価値であることが証明され、長い間見放されてきた。それは、複雑さの一定の成長、ライブラリの成長（そしてopがある）、フレームショット（そしてopがある）を残して、少なくとも複雑さのいくつかの制御を可能にします。
そして、複雑化していることから逃れることはできません。さらに複雑化し、知識の質の要求についていけない無教養な開発者が増えるだろう。
今後、ますます減少するプログラマーの大衆化に合わせて、さらにシンプルな言語を開発する試みが行われるでしょう。間違った技術を信じたばかりに、競争競争に敗れ、不利な立場に立たされるソフトウエア会社がますます増えていくだろう。ただ、競合他社はもっと重くても、製品の成果として有効な技術を使ってくるはずです。
ソフトウェア会社への投資は、昔から命がけです。死亡率や故障率は驚異的で、これからもっとひどくなる。
なぜ？そう、技術ではなく、経済的な要求が大量にあるビジネスだからです。生きているソフトウェア会社の約80％は、マーケティングとセールスで構成されています。間違った技術（ここで多くの人は、想定されるシンプルさを優先する）は、将来の売上を簡単に減少させるのです。なぜなら、より困難な道を歩んで、最終的に良い結果を得たライバルが必ず存在するからです。
さて、10万行までのマイクロプロジェクトについてです。これは、一人の人間の頭の中に収まるチャンスがあり、コントロールできるような錯覚を維持できるため、何でも作ることができるのです。もし、それをスケールアップしようとしたら--痛み、挫折、そして死。
結論
すべては言葉だけの良さ、美しさ...。
OOPを使って大規模で面白いプロジェクトを 作るには、その方法を知ることが必要です。
1 - 方法を知っている人は、ここでµlに行かない、言語はいくつかのプラットフォームに限られており、彼らはすでにビジネスのプロ（他の言語でのプロジェクトを持っている）である...。
2 - そして、その方法を知らない者は、OOPなどを猿のように捻じ曲げ、何も生み出さないだろう...。
そう、もちろん、金融市場のファンも少なからずいるが、本格的に何かをして、人生を切り開くには少なすぎる......。主な関心事は...
つまり、Renat、mt 5はもうすぐ10年になる、10年なんて冗談じゃない...ということです。
そして、OOPプログラミングの適切なトレーニングがない...。
私が書いたトピックは何ですか？OOPについて、そしてその結論は？ゴミの中へ...。
レナートさんに質問なんですが、μlで大きなプロジェクトをプログラムする人は、どこでどのように登場すればいいのでしょうか？
μlで 大規模なプログラミングをする人は、どこからどのように出てくればいいのでしょうか？
これまでも、そしてこれからも、言語やプラットフォームに関係なく、一つの取引所内でアルゴトレーディングの大きなプロジェクトが 行われることはないでしょう。
せいぜい半自動化されたプロジェクトがあるくらいです。
どんな言語でもいいから、セミオートマで大きなプロジェクトを1つでも？スケルパードライブが一番大変です。しかし、決して大衆受けするものではありません。また、質量がないのであれば、なぜわざわざ大きなものを作るのか？片膝をついてマーケット向けのものを作る方が簡単です。