ロシア語でコードを書くこのようなプログラムの長所と短所。 - ページ 3 12345678910...19 新しいコメント TheXpert 2016.10.02 16:36 #21 Реter Konow:1.プログラミング歴は何年ですか？ ユニとは別に11。2.ロシア語でプログラムを書いてみたことは（自分で）ありますか？ もちろんです。問題は、固定観念があり、その人質になっていないかどうかということです。それは、姿勢の問題です。私は英語で書く方があらゆる面で便利なので、好んで使っています。支持する、簡潔である、分かりやすい、コミュニケーションが取れる。英語で書くことに抵抗があるのは、英語をきちんと学ぼうとしないことによるステレオタイプだとさえ言えるでしょう。 Igor-san 2016.10.02 16:38 #22 外部変数がロシア語の場合、サーバーなどシステム上にフォントがない場合、「？1C-そうですね、ロシア語はなんとなくそちらの方が馴染みがありますね。しかし、他の言語では英語だけです（90年代後半に一度、「ロシア語版」Visual Basicを試しましたが、それ以来、私は自分自身を治療しています）。 Vitalii Ananev 2016.10.02 16:41 #23 当初、コンパイラは非ローマ字で書かれた変数名や関数名を全く理解できなかった。コンパイラは 当初、非ラテン文字で書かれた変数名や関数名を理解することができなかった。 Реter Konow 2016.10.02 16:42 #24 Nikolay Demko:まあ、OOPでもロシア語で書けるんですけどね。OOPを否定する切り口は本質的にどうなのか？OOPの本質は、プログラマーが変数のスコープを設定できることです。これを無視したら、何を得ることができるのでしょうか。スコープをコントロールできなくなったので、常に新しいカウンタや変数を使わなければなりません。名前は接尾辞や接頭辞を付けて長く書かなければならない。コードの再利用が できなくなる（OOPの柱の1つ）。もちろん、それがすべてではありませんが、簡単に説明します。どのようなアプローチが良いですか？ついでに言うと、文字入力だけでなく、プログラムを開発する場合、変形する機能は重要です。OOPなら、バイブルを1つ書き換えるだけでいい。他の方法では、プログラム全体を修正する必要があります。また、OOPを使ってロシア語で書くこともできます。私もそう思います。しかし、OOPに関しては私なりの主張があります。この方法の有効性を主張することは、私の実務では完全に否定され、この方法は効果がないと却下されました。本当に、OOPはプログラム言語を「人間化」することはできますが、機械がまったく必要としない不要な存在で埋め尽くされてしまいます。さらに、これらの存在は、人間にとって本当に必要なものではなく、なくても困らないものであることがわかりました。変数のスコープのことでしょうか？グローバルな3次元配列で変数を整理する。この配列の各フィールドをクラスと呼び、フィールドの各列を仮に列挙とします。各変数の値をローカライズするのも、アクセスするのも、とても簡単です...。トランスフォーメーションを考えないと...。論理的なコアで動作するユニバーサルソフトウェアエンジンを作ろうという構想があります。論理チェーンはカーネルで規定される。エンジンは、カーネルを使用して、インデックスによって関数にアクセスすることになります。これは非常に簡単に変形させることができるでしょう。 Mykola Demko 2016.10.02 16:43 #25 Реter Konow: 高度なC++を見よ。このプログラミング言語は、すでに独自のスラングを獲得しているような気がします...。これだけ実体がごちゃごちゃしている言語は、おそらく他にないでしょう。ある程度調べて、必要なものだけを入れておくと、数倍に縮むんですよ。その結果、より多くの人に理解され、親しまれるようになる。しかし、この言語が誰にでも理解でき、親しみやすいものになることを望んでいない人がいて、そのためにものすごく複雑にしているような気がするのですが......。C++では、多くの機能がレイヤー化されています。今でもメインのシステム言語であり、何でも書けるようにするために、さまざまな機能が残されているのです。ACMeからOpenCL、スレッド管理まで。純粋なOOPを求めるのであれば、C#を歓迎します。 Vitalii Ananev 2016.10.02 16:54 #26 このトピックを立てた人は、これまで採用されてきた手続き型プログラミング手法とは対照的に、OOPの利点を十分に理解していないだけなのでしょう。手続き的手法以前は、無条件にジャンプ演算子を使ってプログラムが書かれていた。そして、このように書かれたプログラムは、デバッグやロジックのトレースが非常に難しく、「スパゲッティ・ディッシュ」と呼ばれることさえあった。 Mykola Demko 2016.10.02 16:57 #27 Vitalii Ananev: このトピックを立てた人は、これまで採用されてきた手続き型プログラミング手法とは対照的に、OOPの利点を十分に理解していないだけなのでしょう。手続き的手法以前は、無条件にジャンプ演算子を使ってプログラムが書かれていた。そして、そのように書かれたプログラムは、デバッグやロジックの追跡が非常に困難で、「スパゲッティ・ディッシュ」とまで言われた。 そうですね、後藤は本当に残念です。 Реter Konow 2016.10.02 17:02 #28 私の考え方の原則は次の通りです。1.ソフトウェア機能の呼び出しをインデックス化する。関数そのものを、事象を確認するもの（論理関数、- yes/noを返す）、手続き的なもの（実行関数）、計算関数に分けます。2.グローバルな3次元配列の形で論理コアを作成する。その中で、論理関数のインデックスを一定の階層（チェックするイベントの重要度による区分：グローバルイベントとローカルイベント）で規定した。カーネルのフィールドに、これらのイベントの境界線のようなものを作ります。 3.論理的連鎖の末尾に手続き的関数と計算関数のインデックスを付ける。4.カーネル内のイベントをタイマー頻度でループさせ、そのインデックスを介して必要な関数を呼び出すロジックエンジンを作成する。5.プログラムの再構築は、特定の論理チェーンの再構築または新規の論理チェーンの構築のみとなります。 Реter Konow 2016.10.02 17:08 #29 Комбинатор: ユニとは別に11。 もちろんです。姿勢の問題。私は、あらゆる面で便利な英語の文章を好んで書いています。サポート、簡潔さ、誤解の検索、コミュニティ。英語で書くことに抵抗があるのは、英語をきちんと学ぼうとしないことによるステレオタイプだとさえ言えるでしょう。 ドストエフスキーは英語で読んでいます。そんなことは全然関係ないのですが...。遺伝子レベルでのプログラミングでは、ロシア語の方が都合がいいんです。 Mykola Demko 2016.10.02 17:13 #30 Реter Konow: ドストエフスキーは英語で読んでいます。そんなことは全然関係ないのですが...。ロシア語の方が、私には遺伝子レベルでのプログラミングがしやすいのです。問題ない、47番目の染色体はパワーだ。OOPは頭のいい人たち、教授たちが作ったものです。プログラマーのニーズに合わせて、プログラムを書く のに一番便利なように、何年もかけて微調整や改造をしたのだ。MQのOOPは、コードセーフティという点でも洗練されています。新宗教の預言者になりたい？ 大丈夫、結局はあなたの時代なのです。 12345678910...19 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
1.プログラミング歴は何年ですか？
2.ロシア語でプログラムを書いてみたことは（自分で）ありますか？
問題は、固定観念があり、その人質になっていないかどうかということです。
それは、姿勢の問題です。私は英語で書く方があらゆる面で便利なので、好んで使っています。支持する、簡潔である、分かりやすい、コミュニケーションが取れる。
英語で書くことに抵抗があるのは、英語をきちんと学ぼうとしないことによるステレオタイプだとさえ言えるでしょう。
外部変数がロシア語の場合、サーバーなどシステム上にフォントがない場合、「？
1C-そうですね、ロシア語はなんとなくそちらの方が馴染みがありますね。しかし、他の言語では英語だけです（90年代後半に一度、「ロシア語版」Visual Basicを試しましたが、それ以来、私は自分自身を治療しています）。
まあ、OOPでもロシア語で書けるんですけどね。
OOPを否定する切り口は本質的にどうなのか？
OOPの本質は、プログラマーが変数のスコープを設定できることです。これを無視したら、何を得ることができるのでしょうか。
スコープをコントロールできなくなったので、常に新しいカウンタや変数を使わなければなりません。
名前は接尾辞や接頭辞を付けて長く書かなければならない。
コードの再利用が できなくなる（OOPの柱の1つ）。
もちろん、それがすべてではありませんが、簡単に説明します。
どのようなアプローチが良いですか？
ついでに言うと、文字入力だけでなく、プログラムを開発する場合、変形する機能は重要です。OOPなら、バイブルを1つ書き換えるだけでいい。他の方法では、プログラム全体を修正する必要があります。
また、OOPを使ってロシア語で書くこともできます。私もそう思います。しかし、OOPに関しては私なりの主張があります。この方法の有効性を主張することは、私の実務では完全に否定され、この方法は効果がないと却下されました。本当に、OOPはプログラム言語を「人間化」することはできますが、機械がまったく必要としない不要な存在で埋め尽くされてしまいます。さらに、これらの存在は、人間にとって本当に必要なものではなく、なくても困らないものであることがわかりました。変数のスコープのことでしょうか？グローバルな3次元配列で変数を整理する。この配列の各フィールドをクラスと呼び、フィールドの各列を仮に列挙とします。各変数の値をローカライズするのも、アクセスするのも、とても簡単です...。
トランスフォーメーションを考えないと...。論理的なコアで動作するユニバーサルソフトウェアエンジンを作ろうという構想があります。論理チェーンはカーネルで規定される。エンジンは、カーネルを使用して、インデックスによって関数にアクセスすることになります。これは非常に簡単に変形させることができるでしょう。
高度なC++を見よ。このプログラミング言語は、すでに独自のスラングを獲得しているような気がします...。これだけ実体がごちゃごちゃしている言語は、おそらく他にないでしょう。ある程度調べて、必要なものだけを入れておくと、数倍に縮むんですよ。その結果、より多くの人に理解され、親しまれるようになる。しかし、この言語が誰にでも理解でき、親しみやすいものになることを望んでいない人がいて、そのためにものすごく複雑にしているような気がするのですが......。
C++では、多くの機能がレイヤー化されています。今でもメインのシステム言語であり、何でも書けるようにするために、さまざまな機能が残されているのです。
ACMeからOpenCL、スレッド管理まで。
純粋なOOPを求めるのであれば、C#を歓迎します。
このトピックを立てた人は、これまで採用されてきた手続き型プログラミング手法とは対照的に、OOPの利点を十分に理解していないだけなのでしょう。手続き的手法以前は、無条件にジャンプ演算子を使ってプログラムが書かれていた。そして、そのように書かれたプログラムは、デバッグやロジックの追跡が非常に困難で、「スパゲッティ・ディッシュ」とまで言われた。
私の考え方の原則は次の通りです。
1.ソフトウェア機能の呼び出しをインデックス化する。関数そのものを、事象を確認するもの（論理関数、- yes/noを返す）、手続き的なもの（実行関数）、計算関数に分けます。
2.グローバルな3次元配列の形で論理コアを作成する。その中で、論理関数のインデックスを一定の階層（チェックするイベントの重要度による区分：グローバルイベントとローカルイベント）で規定した。カーネルのフィールドに、これらのイベントの境界線のようなものを作ります。
3.論理的連鎖の末尾に手続き的関数と計算関数のインデックスを付ける。
4.カーネル内のイベントをタイマー頻度でループさせ、そのインデックスを介して必要な関数を呼び出すロジックエンジンを作成する。
5.プログラムの再構築は、特定の論理チェーンの再構築または新規の論理チェーンの構築のみとなります。
ユニとは別に11。
もちろんです。
姿勢の問題。私は、あらゆる面で便利な英語の文章を好んで書いています。サポート、簡潔さ、誤解の検索、コミュニティ。
英語で書くことに抵抗があるのは、英語をきちんと学ぼうとしないことによるステレオタイプだとさえ言えるでしょう。
ドストエフスキーは英語で読んでいます。そんなことは全然関係ないのですが...。ロシア語の方が、私には遺伝子レベルでのプログラミングがしやすいのです。
問題ない、47番目の染色体はパワーだ。
OOPは頭のいい人たち、教授たちが作ったものです。プログラマーのニーズに合わせて、プログラムを書く のに一番便利なように、何年もかけて微調整や改造をしたのだ。
MQのOOPは、コードセーフティという点でも洗練されています。
新宗教の預言者になりたい？ 大丈夫、結局はあなたの時代なのです。