サンセット番組？ - ページ 6 12345678910111213...23 新しいコメント Реter Konow 2020.01.14 12:44 #51 カーソルを使ってEAの内部メモリの動作をボタンで文脈を変えながらコントロールすることができます。 例えば、こんな感じです。 1.ボタンAを押しながらカーソルを右に動かすとアレイのサイズが 大きくなり、左に動かすと小さくなります。 2. Bボタンとマウスの左ボタンを押す - 新しいリソースが作成されます。同時に、チャート上にマスを配置する。 3.Cをクリックし、マス目1（第1の資源）からマス目2（第2の資源）に格納されているデータを移動させる。 4.ボタンDを押して、2つのオブジェクトの間にカーソルを移動させ、それらのパラメータをバインドします（どのパラメータかは、追加のボタンによって異なります）。 などなど・・・。 ここに、ビジュアルプログラミングへの革命と移行の始まりがある)) Реter Konow 2020.01.14 12:56 #52 一般に、カーソルは多機能なツールである。コントロールエレメントを 使わずに、その値のコンテキストを切り替えれば、ほとんど何でもできます。 1.範囲内の値を変更する。 2.レンジバウンダリーの値を変更する。 3.図形を描く。 4.描いた図形をプロセスの中で発表する。 5.フォームの文脈でプロセスを表現すること。 6.オブジェクトのパラメータを関連付ける。 7.内蔵メモリーを管理する。 8.新しいオブジェクト、つまりテンプレートとインスタンスを組み立てる。 9.オブジェクトを破壊する。 10.カーネル内のオブジェクトの位置を変更する場合。 その他にも、いろいろなことがあります。 しかも、既成のウィンドウやエレメント、スタジオを一切使わずに。カーソルとボタンが、異なる文脈でその値を解釈するだけです。 Реter Konow 2020.01.14 13:07 #53 さらに、キーボードの代わりに、視線の方向を登録して文脈を変化させるインタラクティブグローブやメガネを使うことも可能です。そして、未来のプログラミングを手に入れることができるのです)) 要するに、人の視線の焦点を対象物に合わせ、その行動の文脈を制御系が捉えるということに尽きます。 Aleksey Mavrin 2020.01.14 13:27 #54 Dmitry Fedoseev:他にどんなものがあるのでしょうか？ 少なくとも、設計、デバッグ、テストは必要でしょう。 Dmitry Fedoseev 2020.01.14 14:02 #55 Aleksey Mavrin:少なくとも、設計、デバッグ、テストは必要でしょう。 以前、プログラマー（または開発者）が開発者ではなくプログラマーだった頃、その人はプログラミングをするだけで、設計は せず、確かにデバッグやテストもしなかったことが判明した。 Andrey Pogoreltsev 2020.01.14 14:33 #56 Dmitry Fedoseev: 以前、プログラマー（開発者）が開発者ではなくプログラマーだった頃は、プログラミングをするだけで、設計はせず、確かにデバッグやテストもしなかったことが判明した。 パンチカードやマイコンをデバッグする。プログラマーの原型はコーダーである。開発者というのは、まったく別のものです。このスレッドでは、コーダーの衰退を論じ、今日の世界における開発者の本当の姿を理解せずに開発者を暗示しています。 Dmitry Fedoseev 2020.01.14 14:38 #57 Andrey Pogoreltsev: パンチカードやマイコンをデバッグする。プログラマーの原型はコーダーである。開発者というのは、まったく別のものです。このスレッドでは、今日の世界における開発者の本当の姿を理解せずに、開発者を意味するコーダーの衰退を論じています。 パンチカードで打ち出されたプログラムは、即座に絶対的な真理を表し、エラーすら発生しない、ということですか？ マイコンも同じです。マイコンのプログラムは、事前に何も考えず、テストもせずに、即座に、しかも間違いなく書いていたのですか？ Andrey Pogoreltsev 2020.01.14 14:40 #58 Реter Konow: これが革命の始まりであり、ビジュアルプログラミングへの移行である（笑)。 すでに30年ほど前に実施されています。高度に専門化したタスクを記述し、それを開発タスクの全クラスに外挿するのです。 ビジュアル開発は、部分的なものから完全な自動化まで、古くから存在しています。これは、例えば、より高い性能要件が適用される他のクラスのタスクや、視覚環境によって解決されるタスクの開発の必要性を否定するものでは決してありません。どんな普遍主義も遅かれ早かれ怪物に変わるからだ。 Andrey Pogoreltsev 2020.01.14 14:42 #59 Dmitry Fedoseev: では、パンチカードで打ち出されたプログラムは、直ちに絶対的な真理を表し、エラーすら発生しないのですか？ マイコンも同じです。マイコンのプログラムは、事前によく考えず、テストもせずに、一気に、しかもミスなく書き上げたものなのか？ 今更何を言い出すんだ？プログラマーが徐々にデベロッパーになり、ツールの種類やタスクの要求が増えたこと？ それを否定したわけではありません。 Dmitry Fedoseev 2020.01.14 14:44 #60 鉱業...鉱床の開発。石油、ガス、石炭、鉱床の開発...。 デザイナーもデベロッパーに改名されたのかな？建築家？ 12345678910111213...23 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
カーソルを使ってEAの内部メモリの動作をボタンで文脈を変えながらコントロールすることができます。
例えば、こんな感じです。
1.ボタンAを押しながらカーソルを右に動かすとアレイのサイズが 大きくなり、左に動かすと小さくなります。
2. Bボタンとマウスの左ボタンを押す - 新しいリソースが作成されます。同時に、チャート上にマスを配置する。
3.Cをクリックし、マス目1（第1の資源）からマス目2（第2の資源）に格納されているデータを移動させる。
4.ボタンDを押して、2つのオブジェクトの間にカーソルを移動させ、それらのパラメータをバインドします（どのパラメータかは、追加のボタンによって異なります）。
などなど・・・。
ここに、ビジュアルプログラミングへの革命と移行の始まりがある))
一般に、カーソルは多機能なツールである。コントロールエレメントを 使わずに、その値のコンテキストを切り替えれば、ほとんど何でもできます。
1.範囲内の値を変更する。
2.レンジバウンダリーの値を変更する。
3.図形を描く。
4.描いた図形をプロセスの中で発表する。
5.フォームの文脈でプロセスを表現すること。
6.オブジェクトのパラメータを関連付ける。
7.内蔵メモリーを管理する。
8.新しいオブジェクト、つまりテンプレートとインスタンスを組み立てる。
9.オブジェクトを破壊する。
10.カーネル内のオブジェクトの位置を変更する場合。
その他にも、いろいろなことがあります。
しかも、既成のウィンドウやエレメント、スタジオを一切使わずに。カーソルとボタンが、異なる文脈でその値を解釈するだけです。
さらに、キーボードの代わりに、視線の方向を登録して文脈を変化させるインタラクティブグローブやメガネを使うことも可能です。そして、未来のプログラミングを手に入れることができるのです))
要するに、人の視線の焦点を対象物に合わせ、その行動の文脈を制御系が捉えるということに尽きます。
他にどんなものがあるのでしょうか？
少なくとも、設計、デバッグ、テストは必要でしょう。
少なくとも、設計、デバッグ、テストは必要でしょう。
以前、プログラマー（または開発者）が開発者ではなくプログラマーだった頃、その人はプログラミングをするだけで、設計は せず、確かにデバッグやテストもしなかったことが判明した。
以前、プログラマー（開発者）が開発者ではなくプログラマーだった頃は、プログラミングをするだけで、設計はせず、確かにデバッグやテストもしなかったことが判明した。
パンチカードやマイコンをデバッグする。プログラマーの原型はコーダーである。開発者というのは、まったく別のものです。このスレッドでは、コーダーの衰退を論じ、今日の世界における開発者の本当の姿を理解せずに開発者を暗示しています。
パンチカードやマイコンをデバッグする。プログラマーの原型はコーダーである。開発者というのは、まったく別のものです。このスレッドでは、今日の世界における開発者の本当の姿を理解せずに、開発者を意味するコーダーの衰退を論じています。
パンチカードで打ち出されたプログラムは、即座に絶対的な真理を表し、エラーすら発生しない、ということですか？
マイコンも同じです。マイコンのプログラムは、事前に何も考えず、テストもせずに、即座に、しかも間違いなく書いていたのですか？
これが革命の始まりであり、ビジュアルプログラミングへの移行である（笑)。
すでに30年ほど前に実施されています。高度に専門化したタスクを記述し、それを開発タスクの全クラスに外挿するのです。 ビジュアル開発は、部分的なものから完全な自動化まで、古くから存在しています。これは、例えば、より高い性能要件が適用される他のクラスのタスクや、視覚環境によって解決されるタスクの開発の必要性を否定するものでは決してありません。どんな普遍主義も遅かれ早かれ怪物に変わるからだ。
では、パンチカードで打ち出されたプログラムは、直ちに絶対的な真理を表し、エラーすら発生しないのですか？
マイコンも同じです。マイコンのプログラムは、事前によく考えず、テストもせずに、一気に、しかもミスなく書き上げたものなのか？
今更何を言い出すんだ？プログラマーが徐々にデベロッパーになり、ツールの種類やタスクの要求が増えたこと？
それを否定したわけではありません。
鉱業...鉱床の開発。石油、ガス、石炭、鉱床の開発...。
デザイナーもデベロッパーに改名されたのかな？建築家？