私のアプローチコアはエンジンです。 - ページ 19 1...121314151617181920212223242526...184 新しいコメント Vitalii Ananev 2018.12.07 08:00 #181 Реter Konow:わかりました。納得したとしましょう。 OOPは、プログラマーのチームが大きなプロジェクトに取り組むために必要なものです。OOPは、プログラムを組織化し、構造化する。OOPはプログラミング能力を向上させるために多くのツールを提供しています。原理的には、以前からすべて理解していました。そして、私もそれに賛成です。しかし同時に、私なりのアプローチも好んでいます。なぜ? そこには、ある特別な理由がある。 プログラム開発。 //--------------------------------------- OOPと私のアプローチでは、プログラムの開発スピードはどのくらいになるのでしょうか?メカニズムの成長や複雑化には、どちらのアプローチが有利なのでしょうか? 私は、私のアプローチとコード内の母国語(ロシア語60%、英語40%)により、プログラムの急速な成長を最大限に 実現できると結論づけました。 まさに、この急成長こそが私の必要としているものなのです。細かいところを掘り下げない。コードの一行一行に目を通すだけでなくプロフェッショナルなアプローチではありません。 プログラムを早く発展させ、複雑な ものにしたかったのです。その機能を果たすために、機構が作られるのです。素早く、簡単に。 数行のコードで新機能を追加できるように。 私のアプローチは、この特定のタスクを解決する上で、OOPよりも優れています。 なぜ、その方法論が迅速かつ容易な開発を可能にすると思うのですか? 今のところ、私はその逆だと思います。こじつけの話ですが、私もそう思います。あなたのコードは本当に理解しにくいです。 Реter Konow 2018.12.07 08:07 #182 Vitalii Ananev:なぜ、その方法論で素早く簡単に開発できると思うのですか? こじつけについては同感です。あなたのコードは本当に理解しにくいです。今のところ、私はその逆をみています。また、仮想マシン(エンジン)作成の複雑さをどう見積もるのか。マークアップ言語。一人のとんでもない人間がそれを作り出せるのか?OOPでも。 私のアプローチで作ったものを正確に理解していただければ、それがどのようなプログラム開発の機会を提供するものであるかがご理解いただけると思います。(別に不謹慎なことを言っているわけではありません。ただ、そうでなければ理解してもらえないからです) Vitalii Ananev 2018.12.07 08:16 #183 Реter Konow:また、仮想マシン(エンジン)作成の複雑さをどう見積もるのか。マークアップ言語。一人のとんでもない人間がこれを作れるのか?OOPでも。 私のアプローチで作ったものを正確に理解していただければ、それがどのようなプログラム開発の機会を提供するものであるかがご理解いただけると思います。(不謹慎なことは言わない。そうしないと理解されないからだ)少なくとも、あなたはまだ質問に答えていない。実行可能なコードを待って、あなたの熱意がいつまで続くか見てみましょう。 Alexey Navoykov 2018.12.07 10:25 #184 Реter Konow:私のアプローチで作り上げたものを理解すれば、それが提供するプログラム開発の機会も理解できるはずですまあ、パラドックスとは、あなたが作ったものを誰も理解できないということです ) もちろん、あなた以外はね ) Реter Konow 2018.12.07 10:50 #185 Alexey Navoykov:つまり、あなたが作ったものは誰にも理解されないというパラドックスです(もちろん、あなたを除いてですが)。ウィンドウをたくさん描いたり、ビルダーのビデオをたくさん作ったり、ウィンドウ付きの既製のエンジンを提供したり、そのエンジンのコードを知らないままカスタムプログラムにリンクさせたりしました。EAの機能を受け継いだ計算エンジンを作る準備をしているのですが、教育熱心なフォーラムのプログラマーは、私が何をしたのか理解してくれません(笑)。 邪悪な皮肉でしかないのですが...) Реter Konow 2018.12.07 11:03 #186 しかし、この支店は何を作ったかではなく、アプローチの 仕方が重要です。しかし、実績を示すことなく、アプローチの力を示す ことは不可能です。国民はその成果を十分に理解していない。これが普通です。 アチーブメントを理解するには、もともとの問題の複雑さを想像する必要があります。マークアップ言語を作る複雑 さとは何か、という問いに答えよう。 やったことのない人からすると、簡単そうに見えるかもしれませんが、実際には何が必要なのでしょうか? どなたかご存知ですか? Yury Kulikov 2018.12.07 11:34 #187 Реter Konow:マークアップ言語の作成は難しい のか、という問いに答えよう。 やったことのない人からすると、簡単そうに見えるかもしれませんが、実際には何が必要なのでしょうか? どなたかご存知ですか?あなたの言語では、たいしたことはありません。プログラマーにとっては、週末の作業と言えるかもしれません。 Реter Konow 2018.12.07 12:18 #188 Yury Kulikov:あなたの言葉のために、小さな一枚を。プログラマーにとっては、週末の仕事と言えるかもしれません。まあ、こういう答えを想定していたんですけどね。しかし、なぜマークアップ言語を作らないのですか?ずっとグラフィックをやっていて、週末に言語を作ったわけではないのですね)。 私が理解する限り、あなたのウィンドウは標準的なグラフィックライブラリを使用しています(見た目で判断してください)。 グラフィックス・ライブラリーをゼロから自作するとしたら、どれくらいの時間がかかると思いますか? 例えば、アナトリーは1年半かかりました。そして、他人のコードも使っていた。例えば、CCanvasクラス。 しかし、すべてを一から作るとなると、どれくらいの時間がかかるのだろうか。最低でも2年はかかると思います。 図書館だけ ですよ。マークアップ言語ではありません。 TheXpert 2018.12.07 12:24 #189 まだ、検証やソースコードには至っていないということですね? Реter Konow 2018.12.07 12:27 #190 TheXpert: まだチェックやソースコードには至っていないとのことですが?まだです。それはすぐにでも分かることです。まず、この方式を検証するための課題の規模について説明します。 1...121314151617181920212223242526...184 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
わかりました。納得したとしましょう。
原理的には、以前からすべて理解していました。そして、私もそれに賛成です。しかし同時に、私なりのアプローチも好んでいます。なぜ?
そこには、ある特別な理由がある。
プログラム開発。
//---------------------------------------
OOPと私のアプローチでは、プログラムの開発スピードはどのくらいになるのでしょうか?メカニズムの成長や複雑化には、どちらのアプローチが有利なのでしょうか?
私は、私のアプローチとコード内の母国語(ロシア語60%、英語40%)により、プログラムの急速な成長を最大限に 実現できると結論づけました。
まさに、この急成長こそが私の必要としているものなのです。細かいところを掘り下げない。コードの一行一行に目を通すだけでなくプロフェッショナルなアプローチではありません。
プログラムを早く発展させ、複雑な ものにしたかったのです。その機能を果たすために、機構が作られるのです。素早く、簡単に。
数行のコードで新機能を追加できるように。
私のアプローチは、この特定のタスクを解決する上で、OOPよりも優れています。
なぜ、その方法論が迅速かつ容易な開発を可能にすると思うのですか? 今のところ、私はその逆だと思います。こじつけの話ですが、私もそう思います。あなたのコードは本当に理解しにくいです。
なぜ、その方法論で素早く簡単に開発できると思うのですか? こじつけについては同感です。あなたのコードは本当に理解しにくいです。今のところ、私はその逆をみています。
また、仮想マシン(エンジン)作成の複雑さをどう見積もるのか。マークアップ言語。一人のとんでもない人間がそれを作り出せるのか?OOPでも。
私のアプローチで作ったものを正確に理解していただければ、それがどのようなプログラム開発の機会を提供するものであるかがご理解いただけると思います。(別に不謹慎なことを言っているわけではありません。ただ、そうでなければ理解してもらえないからです)
また、仮想マシン(エンジン)作成の複雑さをどう見積もるのか。マークアップ言語。一人のとんでもない人間がこれを作れるのか?OOPでも。
私のアプローチで作ったものを正確に理解していただければ、それがどのようなプログラム開発の機会を提供するものであるかがご理解いただけると思います。(不謹慎なことは言わない。そうしないと理解されないからだ)
少なくとも、あなたはまだ質問に答えていない。実行可能なコードを待って、あなたの熱意がいつまで続くか見てみましょう。
私のアプローチで作り上げたものを理解すれば、それが提供するプログラム開発の機会も理解できるはずです
まあ、パラドックスとは、あなたが作ったものを誰も理解できないということです ) もちろん、あなた以外はね )
つまり、あなたが作ったものは誰にも理解されないというパラドックスです(もちろん、あなたを除いてですが)。
ウィンドウをたくさん描いたり、ビルダーのビデオをたくさん作ったり、ウィンドウ付きの既製のエンジンを提供したり、そのエンジンのコードを知らないままカスタムプログラムにリンクさせたりしました。EAの機能を受け継いだ計算エンジンを作る準備をしているのですが、教育熱心なフォーラムのプログラマーは、私が何をしたのか理解してくれません(笑)。
邪悪な皮肉でしかないのですが...)
しかし、この支店は何を作ったかではなく、アプローチの 仕方が重要です。しかし、実績を示すことなく、アプローチの力を示す ことは不可能です。国民はその成果を十分に理解していない。これが普通です。
アチーブメントを理解するには、もともとの問題の複雑さを想像する必要があります。マークアップ言語を作る複雑 さとは何か、という問いに答えよう。
やったことのない人からすると、簡単そうに見えるかもしれませんが、実際には何が必要なのでしょうか?
どなたかご存知ですか?
マークアップ言語の作成は難しい のか、という問いに答えよう。
やったことのない人からすると、簡単そうに見えるかもしれませんが、実際には何が必要なのでしょうか?
どなたかご存知ですか?
あなたの言語では、たいしたことはありません。プログラマーにとっては、週末の作業と言えるかもしれません。
あなたの言葉のために、小さな一枚を。プログラマーにとっては、週末の仕事と言えるかもしれません。
まあ、こういう答えを想定していたんですけどね。しかし、なぜマークアップ言語を作らないのですか?ずっとグラフィックをやっていて、週末に言語を作ったわけではないのですね)。
私が理解する限り、あなたのウィンドウは標準的なグラフィックライブラリを使用しています(見た目で判断してください)。
グラフィックス・ライブラリーをゼロから自作するとしたら、どれくらいの時間がかかると思いますか?
例えば、アナトリーは1年半かかりました。そして、他人のコードも使っていた。例えば、CCanvasクラス。
しかし、すべてを一から作るとなると、どれくらいの時間がかかるのだろうか。最低でも2年はかかると思います。
図書館だけ ですよ。マークアップ言語ではありません。
まだチェックやソースコードには至っていないとのことですが?
まだです。それはすぐにでも分かることです。まず、この方式を検証するための課題の規模について説明します。