記事"MQLプログラムのグラフィカルインターフェイスのマークアップツールとしてのMQL 第1部"についてのディスカッション - ページ 2 123456 新しいコメント Реter Konow 2020.04.01 00:57 #11 Алексей Мокрушин:... 誰も "ボロクソ "には言っていない。個人的には、著者がマークアップ言語構造の明確な原則を示さなかったのは、それを知らなかったからだ、という妥当な意見を述べた。この記事には、一方では一般的な言葉が多く、他方では不必要な詳細（見抜きゲームのようなもの）がある。著者はまだマークアップ言語の概念を理解しておらず、普通のライブラリをマークアップ言語に変換できると考えている。私たちは、彼が実装計画を説明する瞬間を待っている。個人的には、マークアップ言語を作ったのは私であり、「水が "注ぐ"」ときと「物事が "進む"」ときがよくわかるので、批判する権利がある。この記事にはコンセプトはないが、コンセプトを作ろうとする試みはある。次に何が出てくるか...。著者は意識の流れを "オン "にし、私たちがどのように実装にアプローチできるかを推論しようとしている。実際、彼は記事の中で自らそれを書いている（「POC」コンセプトの実現可能性をテストしている）。 Реter Konow 2020.04.01 01:53 #12 マークアップ言語とは（それがどのような技術で作られたものであれ）、コントロールを 提供するグラフィカルな機能に関するコマンド、C.word、ルール、シンタックスの集合である、と私は言いたい。つまり、理論的には、グラフィカル・ライブラリは、簡略化されたシンタックスとグラフィカルなコンストラクションを簡単に構築できる言語でラップすることができ、ユーザーにとってGUI記述のプロセスをスピードアップし、労力を節約することができるが、そのために必要なことを忘れてはならない：1.ルールと構文を持つ言語を発明する。2.言語 "のコードをMQLコードに翻訳するインタープリターを書く。つまり、ラッパー（マークアップの記述）を対応する機能のライブラリ呼び出しに変換する。この背後には特別なエンジンがあり、その装置は事前によく理解されていなければならない。 Dmitry Fedoseev 2020.04.01 12:22 #13 Алексей Мокрушин:...mqlにはデリゲートがないので、この料理が何なのか、何で食べるのかを考えなければならなかった。標準クラスをすべて書き直さなければならなかった。CObjectから始めた。最終的には、OnTradeTransaction、OnChartEvent、OnTimerイベント処理の簡単な実装を「本物の」OOPの助けを借りて書いた。 . Maxim Kuznetsov 2020.04.01 12:56 #14 Dmitry Fedoseev:. CObjectと"Standard Library"はまだ90年代の遺産である。） インスタンスからの追加属性や "adam"（偉大なクラス／共通の祖先）の存在を必要としない同様のSTLができるまでは、大きな問題があるだろう。クソデカい......。 Dmitry Fedoseev 2020.04.01 13:15 #15 Maxim Kuznetsov:CObjectと"Standard Library"は90年代の遺産だ。）インスタンスからの追加属性や "adam"（偉大なクラス／共通の祖先）の存在を必要としない同様のSTLができるまでは、大きな問題があるだろう。クソデカい......。オブジェクトはここでは重要ではない。OOP＝パターンであり、パターンの力が使われる場所とOOPの力が使われる場所を混同してはならない。expressoを書くときにOOPやテンプレートが特別に必要なことはないし、関数へのポインタがある一方で、OOPを使ってデリゲートのアナログを作ることもない。 悲しいことだが、「C++被害者クラブ」という冗談が現実になりつつある。不思議なもので、人々は自分自身にいろいろないじくり回しを重ね、それをクールなコーディングだと考えている。しかし実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。 Maxim Kuznetsov 2020.04.01 13:30 #16 Dmitry Fedoseev:ここではCObjectがメインではない。OOP＝テンプレートであり、テンプレートの力が使われる場所とOOPの力が使われる場所を 混同してはならない。関数へのポインタがある一方で、OOPを使ってデリゲートのアナログを作成することもない。 悲しいことだが、「C++被害者クラブ」という冗談が現実のものとなってしまった。不思議なもので、人々は自分自身にいろいろな種類の小細工を積み重ね、それをクールなコーディングだと考えている。しかし実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。 "何の力だ、兄弟？" ライブラリー・プラッガーが支配するべきだ。コード・サイズと開発時間を削減できるのであれば、それは実際に正しいことなのだ。 追記／これまでのところ、発表されたすべての記事（そしてその発展、より重要なのは）は、プログラミングのアンチテーゼである。 Dmitry Fedoseev 2020.04.01 13:38 #17 Maxim Kuznetsov:"パワーは何だ、兄弟？"library_pluginsが支配するべきだ。コード・サイズと開発時間を削減できるのであれば、それは実際に正しいことなのだ。追記／これまでのところ、発表されたすべての記事（そしてその発展形、より重要なこと）はプログラミングのアンチテーゼである。 パワーは知識にあり、記事は知識を与えるだけで、他に与えるべきものはない。効率を上げることは、誰にとっても個人的な問題である。プログラミングの効率を上げることは確かに良いことだが、それがプログラムの使用者の快適さを失わせるようなものであってはならない。 Реter Konow 2020.04.01 15:04 #18 Dmitry Fedoseev:... 実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。 高等教育を受けなくても、「知的に発達した」IDEのサポートがあれば、「半語」から構築される論理構造の本質を「理解」し、直感的に「オブジェクト」（あらかじめ定義されたリンクを持つパラメーターの名前付きグループ）を構築することができるようになるのだから。環境は賢くなり、専門プログラマーと多様な言語の時代は終わるだろう。誰もがプログラムの命令を読むことでアルゴリズムを構築できるようになる。自然な流れで、何も心配することはない......。それがもっと早く始まらなかったのが不思議なのだが、その代わりに1つのコンセプトをさまざまな方法で繰り返す言語が増殖してきた。 Stanislav Korotky 2020.04.01 16:02 #19 XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的で、必要な人には十分な拡張性がある。内部構造に立ち入らないことも可能だろう。ただ、コンセプトや装置の説明がないよりはあったほうがいいのが普通だ。 私も標準ライブラリに 夢中になっているわけではないが、選択肢は多くないので、（今のところ）とにかく大きな疑問がある数少ない非常に小さなライブラリと超派手なライブラリの間の最良の妥協点なのだ。 プログラミングやGUI制作の大御所と言われる人たちは、素朴な手際の良さを根拠にそう宣言したのだから、自分のスレッドでその手際の良さを発揮することをお勧めする。 Реter Konow 2020.04.01 16:33 #20 Stanislav Korotky:...プログラミングやGUI制作において、素朴な技巧を根拠にそう宣言した架空の著名人は、自分のスレッドでその手腕を発揮することをお勧めする。 ビンゴ。 123456 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
...
...mqlにはデリゲートがないので、この料理が何なのか、何で食べるのかを考えなければならなかった。標準クラスをすべて書き直さなければならなかった。CObjectから始めた。最終的には、OnTradeTransaction、OnChartEvent、OnTimerイベント処理の簡単な実装を「本物の」OOPの助けを借りて書いた。
.
.
CObjectと"Standard Library"はまだ90年代の遺産である。）
インスタンスからの追加属性や "adam"（偉大なクラス／共通の祖先）の存在を必要としない同様のSTLができるまでは、大きな問題があるだろう。クソデカい......。
CObjectと"Standard Library"は90年代の遺産だ。）
インスタンスからの追加属性や "adam"（偉大なクラス／共通の祖先）の存在を必要としない同様のSTLができるまでは、大きな問題があるだろう。クソデカい......。
オブジェクトはここでは重要ではない。OOP＝パターンであり、パターンの力が使われる場所とOOPの力が使われる場所を混同してはならない。expressoを書くときにOOPやテンプレートが特別に必要なことはないし、関数へのポインタがある一方で、OOPを使ってデリゲートのアナログを作ることもない。
悲しいことだが、「C++被害者クラブ」という冗談が現実になりつつある。不思議なもので、人々は自分自身にいろいろないじくり回しを重ね、それをクールなコーディングだと考えている。しかし実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。ここではCObjectがメインではない。OOP＝テンプレートであり、テンプレートの力が使われる場所とOOPの力が使われる場所を 混同してはならない。関数へのポインタがある一方で、OOPを使ってデリゲートのアナログを作成することもない。
悲しいことだが、「C++被害者クラブ」という冗談が現実のものとなってしまった。不思議なもので、人々は自分自身にいろいろな種類の小細工を積み重ね、それをクールなコーディングだと考えている。しかし実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。"何の力だ、兄弟？"
ライブラリー・プラッガーが支配するべきだ。コード・サイズと開発時間を削減できるのであれば、それは実際に正しいことなのだ。
追記／これまでのところ、発表されたすべての記事（そしてその発展、より重要なのは）は、プログラミングのアンチテーゼである。
"パワーは何だ、兄弟？"
library_pluginsが支配するべきだ。コード・サイズと開発時間を削減できるのであれば、それは実際に正しいことなのだ。
追記／これまでのところ、発表されたすべての記事（そしてその発展形、より重要なこと）はプログラミングのアンチテーゼである。
パワーは知識にあり、記事は知識を与えるだけで、他に与えるべきものはない。効率を上げることは、誰にとっても個人的な問題である。プログラミングの効率を上げることは確かに良いことだが、それがプログラムの使用者の快適さを失わせるようなものであってはならない。
... 実際、現代のプログラマーはライブラリー・プラッガーに成り下がっている。
高等教育を受けなくても、「知的に発達した」IDEのサポートがあれば、「半語」から構築される論理構造の本質を「理解」し、直感的に「オブジェクト」（あらかじめ定義されたリンクを持つパラメーターの名前付きグループ）を構築することができるようになるのだから。環境は賢くなり、専門プログラマーと多様な言語の時代は終わるだろう。誰もがプログラムの命令を読むことでアルゴリズムを構築できるようになる。自然な流れで、何も心配することはない......。それがもっと早く始まらなかったのが不思議なのだが、その代わりに1つのコンセプトをさまざまな方法で繰り返す言語が増殖してきた。
XMLはないだろう。要はMQLなしでやるということだ。ゴールはMQLに "ネイティブな "MVPレベルのマークアップシステムを作ることだ。飾り気はないが、機能的で、必要な人には十分な拡張性がある。内部構造に立ち入らないことも可能だろう。ただ、コンセプトや装置の説明がないよりはあったほうがいいのが普通だ。
私も標準ライブラリに 夢中になっているわけではないが、選択肢は多くないので、（今のところ）とにかく大きな疑問がある数少ない非常に小さなライブラリと超派手なライブラリの間の最良の妥協点なのだ。
プログラミングやGUI制作の大御所と言われる人たちは、素朴な手際の良さを根拠にそう宣言したのだから、自分のスレッドでその手際の良さを発揮することをお勧めする。
...
プログラミングやGUI制作において、素朴な技巧を根拠にそう宣言した架空の著名人は、自分のスレッドでその手腕を発揮することをお勧めする。
ビンゴ。