MQL5言語をゼロから独学で学ぶ - ページ 17

 
Roman:

あなたとは正反対!
プログラミングで一番大切なことは、言語を最低限知っておくことです
初心者にとって、低レベルとは、追加のコードラッパーがない言語の構文のことです。
分解についてはどうかというと、おっしゃるとおり、フローチャートがどのように構成されるかを理解することです。
だからこそ、プログラマーは哲学的な空想ではなく、言語に関する実践的な知識によって評価されるのです。
言葉の基本がないのに、どうやって妄想するんだ?シンプルなロジックはどこにあるのでしょうか。
このスレッドの著者である電子工学技術者の言葉に相当し、まず基板に電圧を供給し、なぜ基板が焼けたのか不思議に思う ))

私はそうは思いません。目標を設定するときは、その言語を知らなくても、その能力を理解すればいいのです。しかし、目標を設定し、それを解決し、アルゴリズムを選択し、コーディングするとき、これらのすべての段階でそれは必要である。言語の構文を 知らずに問題を設定することは、実装上大きな問題となることがあります)))

 
Roman:

...等価なのは、このスレッドの著者である電子用語で、まず基板に電圧をかけ、なぜ基板が焼けたのか不思議に思うことです ))

ローマンさん、こんにちは。素晴らしい比較です。今は、トランジスタの原理を知っている状態から、デジタル回路の原理を学んだK155と同じレベルの電子工学エンジニアとしてプログラミングに取り組んでいます。

しかし、1983年当時、私の同僚たちの多くは、トランジスタの働きを全く理解しないまま、EUシリーズのコンピュータを修理していた。論理学の代数学さえ知っていればいいのだ。余談ですが、ソ連時代のノスタルジー!?

ウラジミールさん、ありがとうございます。

 
Valeriy Yastremskiy:

私はそうは思いません。目標を設定するとき、言葉を知っている必要はなく、その能力を理解することが必要です。しかし、問題設定、問題解決、アルゴリズム選択、コーディングにおいては、これらすべての段階が必要である。言語の構文を 知らずに問題を設定することは、実装上大きな問題となることがあります)))


問題の定義は、言語の基本をマスターするための極限の段階であり、変数とは何か、どんな大きさにできるか、スコープなどをすでに理解している場合である。
また、何から手をつけていいのか、何語を学べばいいのか、すべてを理解できるのか、岐路に立たされたこともありました。真実を知るために何カ国語も試したのですから、苦しかったですね。
しかし、ようやくmqlがC言語ライクな言語であることに気づき、C言語を基礎から目的意識を持って勉強するようになったのです。
そして、基本的な勉強を終えたとき、私はすでに実質的にmqlを知っていて、すべてが明確であることに驚きました、唯一の構文と仕様がドックで改善されるべきです、それはmqlの機能です。
プログラミングの手続き的なアプローチを理解した私は、1年後にOOPに手を出し始めました。長い間、同じものの別の呼び名があり、よくわかりませんでした。
例えば、メソッドと関数、何が違うのか )) 変数とクラスメンバ )) など
しかし、そこに至るには、手続き的アプローチの根幹を理解する必要があり、OOP用語を徐々に理解し始めると、理解が一気に広がります。
それが、最初の学習経路の選択という違いです。文字や句読点を知らずにどうやってロシア語で書くんだ?
フックとスティックから始めたことを思い出してください。

 
Roman:

あなたとは正反対!
プログラミングの決め手は、なるべく低いレベルの言語の知識なのです

何を得ることができるのか?超低レベルの言語を知っている。アセンブラコマンドがifに置き換わったり、forループがgotoに変換されたりするのはご存知の通りです。アセンブラを知ってるんですね。どこに利益があるんだ?Pythonのプログラマーを見てください。彼らは何も知らないのです。しかし、彼らは関数の扱いに長けており、Map/Reduceの方法を知っています。それらを合成して、お互いにインプットすることができるのです。また、Pythonに比べてMQLはあまり書かれなくなったので、今はどこにあるのでしょうか?

ローマ字 表記

語学の基礎がないのに、どうして派手にできるのか?シンプルなロジックはどこにあるのでしょうか。
このスレッドの筆者である電子言語と似ていて、まず基板に電圧を供給し、なぜ基板が焼けたのか不思議に思う ))

あなたの理解する単純な理屈では、市販されているものである。私が思うに、それはアセンブリ言語のようなもので、「私が見たものは、私が歌うもの」なのです。そこに論理性はなく、ただの馬鹿なタイピングスキルです。タイピストでも2週間の講習を受ければできるようになる。それはプログラミングではありません。

ローマ字 表記

あなたの言う「分解」に関係するのは、フローチャートがどのように構成されているかという理解です。

フローチャートは手続き型言語のための図である。"ここがforループ、ここがifループ "と。今時、手続き型言語で書く 人はいないでしょう。ユーザーアプリケーションが、例えばCやPascalを選択するのはナンセンスです。OSのカーネルや他の手続き型言語には最適です。しかし、これはタスクのごく一部であり、明らかにタスクの範囲外である。
 
Vasiliy Sokolov:

そして、そのような知識を得ることで何が得られるのでしょうか。超低レベルの言語を知っている。アセンブラコマンドがifに置き換わったり、forループがgotoに変換されたりするのはご存知の通りです。アセンブラを知ってるんですね。どこに利益があるんだ?Pythonのプログラマーを見てください。彼らは何も知らないのです。しかし、彼らは関数の扱いに長けており、Map/Reduceの方法を知っています。それらを合成して、お互いにインプットすることができるのです。また、Pythonでそれほど書いていない今時のMQLはどこにあるのでしょうか?

単純なロジックの理解では、恐ろしく手続き的なことなんですね。私のロジックの理解では、アセンブラでいうところの「見たまま、歌ったまま」という感じです。そこに論理性はなく、ただの馬鹿なタイピングスキルです。タイピストでも2週間の講習を受ければできるようになる。プログラミングではありません。

フローチャートは、手続き的なJDのための図である。"ここがforループ、ここがifループ "と。今時、手続き型言語で 書くことはないでしょう。ユーザーアプリケーションが、例えばCやPascalを選択するのはナンセンスです。OSのカーネルや他の手続き型言語には最適です。しかし、それはタスクの中のほんの僅かな割合であり、明らかにタスクの範囲外である。
Vasilyさん、TCにOOPパラダイムでのプログラミングを教えるのに、彼が持っていない初歩的なことを避けて、どうやって想像するのですか?)いや、まあ、可能性はあるのかもしれないけど、想像がつかない...。

プログラミングのアルゴリズム(ルーチン)=間違ったアプローチ」と説明するように。ソフトウェア環境内で、互いの特性やメソッドを継承する「オブジェクト」と呼ばれる概念的に完全で階層的なパターン化されたシステムをプログラミングする必要があります」。

そして、すぐに「あ~あ、なんで今までそう言わなかったんだ!」と。全てに意味がある」)))
 
Vasiliy Sokolov:

そして、そのような知識を得ることで何が得られるのでしょうか。超低レベルの言語を知っている。アセンブラコマンドがifに置き換わったり、forループがgotoに変換されたりするのはご存知の通りです。アセンブラを知ってるんですね。どこに利益があるんだ?Pythonのプログラマーを見てください。彼らは何も知らないのです。しかし、彼らは関数の扱いに長けており、Map/Reduceの方法を知っています。それらを合成して、お互いにインプットすることができるのです。また、Pythonでそれほど書いていない今時のMQLはどこにあるのでしょうか?

単純なロジックの理解では、恐ろしく手続き的なことなんですね。私のロジックの理解では、アセンブラでいうところの「見たまま、歌ったまま」という感じです。そこに論理性はなく、ただの馬鹿なタイピングスキルです。タイピストでも2週間の講習を受ければできるようになる。プログラミングではありません。

フローチャートは手続き型言語のためのスキーマである。"ここがforループ、ここがifループ "と。今時、手続き型言語で書く 人はいないでしょう。ユーザーアプリケーションが、例えばCやPascalを選択するのはナンセンスです。OSコアなどの手続き型言語には最適です。しかし、これはタスクのごく一部であり、明らかにタスクの範囲外である。

PythonはC言語で書かれていることをご理解ください。
そして、Pythonはコードを書きやすくするために設計されました。しかし、そのシンプルさから人気言語になったものの、コーダーの知識はPythonのレベルにとどまっています。
そして、C言語を知っている プログラマーだけが、ライブラリや追加的なものを書いているのです。彼らはプログラマーであって、コーダーではない。
単純なコードタイピストが理解力でコーダーに勝つという点です。
あなたはただのC#ニクだからそんな顔をしていますが、このC#言語が何語で書かれているかも考えないでください))

 
Roman:

では、機能を知らないのにどうやって機能を理解するのか ))
問題設定は、言語の基本をマスターするための極限の段階であり、変数とは何か、どんな大きさにできるか、スコープなどはすでに理解している場合です。
また、何から手をつけていいのか、何語を学べばいいのか、すべてを理解できるのか、岐路に立たされたこともありました。真実を知るために何カ国語も試したのですから、苦しかったですね。
しかし、ようやくmqlがC言語ライクな言語であることに気づき、目標を持って基礎からC言語を学ぶようになったのです。
そして、基本的な勉強を終えたとき、私はすでに実質的にmqlを知っていて、すべてが明確であることに驚きました、唯一の構文と仕様がドックで改善されるべきです、それはmqlの機能です。
プログラミングの手続き的なアプローチを理解した私は、1年後にOOPに手を出し始めました。長い間、同じものの別の呼び名があり、よくわかりませんでした。
例えば、メソッドと関数、何が違うのか )) 変数とクラスメンバ )) など
しかし、そこに至るには、手続き的アプローチの根幹を理解する必要があり、OOP用語を徐々に理解し始めると、理解が一気に広がります。
それが、最初の学習経路の選択という違いです。文字や句読点を知らずにどうやってロシア語で書くんだ?
フックとスティックでスタートしたところを思い返してみてください。

なんて言ったらいいのかわからない。人それぞれ、やり方があるんでしょうね。私は主張しない。しかし、ゴールは異なる言語で解くことができ、ゴールを選択する際に構文を知らずに可能性だけを知ることができる。pythonでWebサイトを作るためのライブラリがあり、サイトはpythonでもpxpでもjumlaでもhtmlでも何でもよく、価格とすぐに使える機能(スクリプト)の有無が問題で、これは問題提起であり、言語に対する深い知識が必要です。MKL、Python、R、Matlabのスクリプトを選択してシリーズを操作することができます。MAによる注文の設定には、ネイティブMCLで十分です。

すべてが調和していなければならないのです。クルマの仕組みを知っていることと、上手に運転することは別です。でも、仕組みがわからないと、出先での故障に不利です(笑)。

また、人それぞれですが、優れたコーダーが優れたアルゴリズム研究者でないこともよくありますし、その逆もしかりです。これらの資質が相まって良いものであれば、普通にカッコよくて高いのですが、そうでもないようです。)))

 
もちろん、手続き的なアプローチでは、プログラマは、膨大な数のレディメイドのソリューションを含む巨大なOOPライブラリから孤立することになります。そして、この「孤立」は、彼のコーディングのレベルに確実に影響を及ぼしているのです。しかし、ベースをマスターして初めてライブラリに到達することができる。つまり、最初の理論と実践の土台がしっかりしているだけで、フラットな機能命令ではなく、オブジェクト環境としてプログラムを構成することが可能なのです。もちろん、イミフです。
 
Vasiliy Sokolov:

そして、そのような知識を得ることで何が得られるのでしょうか。超低レベルの言語を知っている。アセンブラコマンドがifに置き換わったり、forループがgotoに変換されたりするのはご存知の通りです。アセンブラを知ってるんですね。どこに利益があるんだ?Pythonのプログラマーを見てください。彼らは何も知らないのです。しかし、彼らは関数の扱いに長けており、Map/Reduceの方法を知っています。それらを合成して、お互いにインプットすることができるのです。また、Pythonでそれほど書いていない今時のMQLはどこにあるのでしょうか?

単純なロジックの理解では、恐ろしく手続き的なことなんですね。私のロジックの理解では、アセンブラでいうところの「見たまま、歌ったまま」という感じです。そこに論理性はなく、ただの馬鹿なタイピングスキルです。タイピストでも2週間の講習を受ければできるようになる。プログラミングではありません。

フローチャートとは、手続き型言語のフローチャートです。"ここがforループ、ここがifループ "と。今時、手続き型言語で書く 人はいないでしょう。ユーザーアプリケーションが、例えばCやPascalを選択するのはナンセンスです。OSのカーネルや他の手続き型言語には最適です。しかし、これはタスクのごく一部であり、明らかにタスクの範囲外である。

多いんです、正しいやり方が。理想は、お客様が優秀なコーダーであることです)))どれだけの神経が節約できることか)))

低レベルの言語を知っていても、高レベルの言語の知識が無効になるわけではなく、プログラムがどのように動作するかをより深く理解することができるようになるだけです。また、ループがどのように動作し、どの程度のメモリを消費するのかが分かれば、必要に応じて最適化することができる。それ以上はない。

正直なところ、論点がよくわからない。

 
Valeriy Yastremskiy:

...

正直言って、論点がよくわからないんです。

Vasilyは、OOPそのもの以外は二の次というOOP思考を初心者に教えようと思っているのだと思います。変数、演算子、配列から始めるのではなく、クラス、プロパティの継承、オブジェクト階層の構築、強力なライブラリの接続から始めてください。保育園」から転園してそのまま大学へ)))