記事「ビジュアルプログラミング言語DRAKON：MQL開発者と顧客のコミュニケーションツール」についてのディスカッション

[MetaQuotes]

新しい記事「ビジュアルプログラミング言語DRAKON：MQL開発者と顧客のコミュニケーションツール」はパブリッシュされました:

DRAKONは、ロシアの宇宙プロジェクト（例えば、「Buran」再利用可能宇宙船プロジェクト）のプログラマーと、異なる分野の専門家（生物学者、物理学者、エンジニアなど）との対話を簡素化するために設計されたビジュアルプログラミング言語です。この記事では、DRAKONが、コードに触れたことがない人にとっても、アルゴリズムの作成にアクセスしやすく、直感的にし、また、顧客が取引ロボットを注文する際に自分の考えを説明しやすくし、複雑な関数でプログラマーのミスを少なくする方法についてお話します。

これによってプログラマーの技術的作業の負担が減るわけではありませんが、少なくともあなたの考えをよりよく理解できるようになるし、最初のバージョンでミスを犯す可能性も少なくなります。これらのエラーは最終的に修正しなければなりませんが、それにはさらなる時間（および/または費用）が必要になるかもしれません。

一般的に、DRAKON図は、プログラマーにとっても、プログラミングに不慣れだがEAを性格にどのように動作させたいかを正確に理解している顧客にとっても有益です。

端的に言えば、次のようになります。

• 言葉の構成は、本当に考える助けになります。図という形でアルゴリズムを見ると、モジュール内の部分間の関係やモジュール自体の関係を理解するのがずっと簡単になり、図がなければわからないようなエラーを見つけたり、解決策を使ったりすることもできます。
• DRAKONは顧客をよりよく理解するのに役立ちます。
• もし何か提案があれば、それを顧客に伝えやすくなります。
  
• 顧客が私のミスを批判するのがより簡単になります。
• 顧客がDRAKON図を描いていれば、それをコードに移し替えて要求仕様が完成したとみなすことができます。これは、コーディング中に生じる疑問や問題に対処するよりもはるかに簡単です。顧客にとっては明らかでも、開発者にとってはそうでない機能があるかもしれません。この図は、潜在的な誤解をなくすものです。
  

私にとって、アルゴリズムにおけるグラフィックは不可欠なコミュニケーションツールです。2人の人間が結果に興味を持ち、対話をする場合、同じ言語を話す方が良くなります。DRAKON図の言語は、一度理解すればどの分野の専門家にとっても普遍的です。

作者: Oleh Fedorov

[Dmitry Fedoseev]

呪われそうだった：

私は驚きながら看板を読んだ。看板は3つあった。左のゲートには、銀色の 文字が入った青い看板が厚いガラスで厳かに光っていた。

nichavo
鶏の足の小屋
ソロヴェツキー古代の記念碑

右の門には錆びたブリキ板が上からかかっていた。「ルコモリェ通り、N_13、N. K. Gorynych」。その下にはベニヤ板があり、

。インクで曲がりくねった線が書かれていた。

猫が動かない

管理

[Stanislav Korotky]

関連記事

[Oleh Fedorov]

Dmitry Fedoseev #:

それで思い出した：

私は驚きながら看板を読んだ。

...

この連想について、もう少し詳しく説明してもらえますか？

追伸：私も「Monday」が大好きです。彼らの他の作品も。

[Oleh Fedorov]

Stanislav Korotky #:
関連記事

スーパーありがとう

[Dmitry Fedoseev]

Oleh Fedorov #:

この協会についてもう少し詳しく教えてください。

追伸：私も『Monday』が大好きです。彼らの他の作品も。

特にありません。冒頭の「DRAGON言語は連邦宇宙局の共同作業によって開発された」という言葉がシュールすぎて、一瞬ストルガツキーでも読んでいるのかと思った。

[Soewono Effendi]

Flowgorithmを試して みるといいかもしれない。

[Alexey Volchanskiy]

Dmitry Fedoseev #:

特別なことは何もない。DRAGON言語は連邦宇宙局の共同作業によって開発された」という冒頭はとてもシュールで、一瞬ストルガツキーでも読んでいるのかと思った。

恐ろしい光景だ！自動着陸を実現するために、ビュランのソフトウェア開発者がどれだけの図を描かなければならなかったかを想像すると、涙が出てくる！

[Oleh Fedorov]

Alexey Volchanskiy #:

恐ろしい光景だ！自動着陸を実現するために、Buranのソフトウェア開発者がどれだけの図を描かなければならなかったかを想像すると、私の目には涙が浮かんでくる！

重要なのは、DRAGONを使ったプロジェクトでは、設計局はプログラマーを雇うことを拒否していたということだ。プログラムはアプリケーション・エンジニア、つまりフェイルセーフ・アルゴリズムをすべて担当しなければならないエンジニアによって書かれた。彼らは、少なくとも部門間の相互作用のために、いずれにせよこれらのスキームを描かなければならなかっただろう。したがって、この技術の有用性は、個人的にはかなり具体的なものに思えるのだが......。

[Oleh Fedorov]

Soewono Effendi #:
Flowgorithmを試して みるといいかもしれない。

とても面白そうだ。

チャット形式のコンソールは僕にはあまり向いていないけど、面白いものがたくさんあるよ。

[lepine code]

Flowgorithmは実世界のプログラミングよりも教育的な目的に向いている。Drakonは僕が探しているものに近い：Grafcetに近い。フランスとオートメーション分野以外ではあまり知られていないが、宝石のようなものだ ;) https://www.researchgate.net/profile/Paul-Baracos-2/publication/243782363_Grafcet_step_by_step/links/588b7e3d45851567c93c9cdb/Grafcet-step-by-step.pdf

昔、フランスの工学学校（コンピュータサイエンスではなく、伝統的な工学分野）で、委員会の一員だった先生から教わったことがある。習う前はコーディングに全く興味がなくて、ほとんどビリだったんだけど、習ったらビリになったよ。）

その後、伝統的なソフトウェア・エンジニアリングの世界にいたので、そのことは忘れていました。何十年も経ってから、伝統的なソフトウェアエンジニアリングには本当のモデリングがないことに気づいたんだ。SFCは確かにGrafcetから派生したものだが、特定の業界（オートメーション）のためのコーディング言語であり、仕様のためのものではない。

GRAFCETの主な利点の1つは階層構造の仕様化である」https://www.sciencedirect.com/science/article/pii/S2405896319314387 、イベント駆動型なのでトレーディング・アルゴリズムに非常に適している。）