ビジュアルプログラミング言語

私たちのほとんどは、Basic、C / C ++、Javaなどの「テキスト」プログラミング言語を使用してプログラミングを学びました。人間が視覚的に考える方が自然で効率的だと思います。ビジュアルプログラミングにより、開発者はグラフィカル要素を操作してプログラムを作成できます。ビジュアルプログラミングを使用すると、コードの品質が向上し、プログラミングのバグが減少するはずです。App Inventor、Scratch、LabViewなどのいくつかの視覚言語を知っています。

開発者向けの主流の汎用視覚言語がないのはなぜですか？ビジュアルプログラミングの長所と短所は何ですか？

一般に、プログラミング言語の設計には、使いやすさと表現力（パワー）の間でトレードオフがあります。ScratchやApp Inventorなどの初心者言語で簡単な「Hello、world」プログラムを作成する方が、JavaやC ++などの汎用プログラミング言語で作成するよりも一般的に簡単です。出力、異なる文字セット、構文を変更する機会、動的タイプなど。

App Inventor（私が所属していた）の作成中、私たちの設計哲学は、初心者にとってプログラミングを簡単にすることでした。些細な例では、配列インデックスを0ではなく1に基づかせていましたが、上級プログラマーによって計算が実行される可能性が多少複雑になりますが。

ただし、ビジュアルプログラミング言語が初心者向けに設計される傾向がある主な方法は、構文的に無効なプログラムを作成できないようにして、構文エラーの可能性を排除することです。たとえば、ブロック言語では、右辺値を割り当てステートメントの宛先にすることはできません。この哲学は、より単純な文法と言語を生み出す傾向があります。

ユーザーがブロック言語でより複雑なプログラムの構築を開始すると、ブロックのドラッグアンドドロップは入力よりも遅いことがわかります。「a * x ^ 2 + b * x + c」と入力するか、ブロックで作成しますか？

いくつかの段落でこのトピックに正義を与えることはできません（少なくとも私は）が、主な理由のいくつかは次のとおりです。

1. ブロック言語は初心者向けに設計される傾向があるため、設計上それほど強力ではありません。
2. 型システムなど、汎用プログラミング言語で見られる複雑な概念を表現するための視覚的な方法はありません。
3. 複雑なプログラムでは、ブロックの使用は扱いにくいです。

開発者向けの主流の汎用視覚言語がないのはなぜですか？ビジュアルプログラミングの長所と短所は何ですか？

視覚言語は、大きく3つのカテゴリに分類される傾向があります。

1. 非プログラマーにツールを提供して、基本的な自動化タスクを実行します。MacのAutomatorを考えてください。
2. 大量のタイピングが実用的ではない学習環境、または論理的な流れを示すプログラムの構造が重要な学習環境。スクラッチ、アリスなどを考える
3. 対処されている問題はデータフローの問題であり、問​​題の解決策は、物理世界を模倣する自己完結型ボックス間の何らかのデータフローによってうまくモデル化されています。LabViewとAbletonの両方が思い浮かびます。

ビジュアルプログラミングの利点は、システム構造の概要を把握できることです。これは、詳細を取得すると、スパゲッティコードが実際にスパゲッティのように見えるという差し迫った問題につながります。視覚言語の一般的なコンポーネントは、視覚要素の何らかのコードブロックまたは構成コンポーネントです。問題は、プログラマーが、奇妙な方法で相互リンクされる可能性のある切断されたコードブロックを理解する必要があることです。

ビジュアルプログラミングには何の問題もありませんが、ほとんどのタスクには適切なアプローチではない可能性があります。

次の2つの参考文献が示すように、vlib.orgとoregonstate.eduのように、多数の視覚プログラミング言語がありました。

彼らはおもちゃの例には適していますが、大規模なプロジェクトに必要な複数レベルの抽象化、表現、粒度を管理できないため、トラクションを獲得できませんでした。AutoDesk Revit（建築家やエンジニアが使用する建物情報管理システム）のようなシステムを見て、視覚情報の管理がいかに複雑になるかを確認する必要があります。

視覚的なプログラミングは、汎用プログラミングを検討するのではなく、専門分野の構成ツールとして成功する可能性が最も高くなります。

テキストは視覚的です。

コードでは、あらゆる種類の視覚的キューを使用します。空白（インデント、改行、空白行、行内間隔）の使用はすべて、コードの機能の視覚的な合図を提供することに向けられています。あらゆる種類の異なる構文を使用して、コードの実行内容に関する視覚的な情報を提供します。エディターがコードを色付けして目立つようにします。

数学はテキストです。あらゆる種類の表記法がありますが、最終的には基本的にテキストになります。彼らは何百年もやっています。

私のポイント：コードのテキスト表現は、人間が持っている視覚能力を利用しています。おそらくそれをもっとうまく利用することはできますが、テキストを放棄することはできません。

[この返信のPDFバージョンでは、図または図はインタラクティブで動的です。]

ネット要素と注釈：汎用視覚プログラミング言語

グラフィックを使用して、Acrobat®/ JavaScript APIを使用するJavaScript™プログラムを編成します。各グラフィックオブジェクトは、ペトリネット要素（場所、遷移、入力または出力）を表すか、複数のペトリネット要素を表します。各グラフィックオブジェクトは、実際には対応するネット要素の注釈です。ただし、すべてのグラフィックオブジェクトが1つだけのネット要素にマップされる場合、それを使用してネット要素を生成できます。また、グラフィックオブジェクトが複数のネット要素にマップされ、そのマッピングが明確に定義されている場合は、ネット要素の生成にも使用できます。標準のペトリネット要素は、特定の種類のグラフィックスで表されます。円は場所、正方形または長方形または線は遷移、円から正方形への矢印は入力、正方形から円への矢印は出力。さらに、

[「標準ペトリネット」の注釈のタイプは、この返信のPDFバージョンにあります。]

カールアダムペトリは、これらのアイデアの大部分（博士論文（ペトリ、1966年）の「標準ペトリネット」の注釈のタイプを含む）を説明しました。また、ネット要素と注釈を図6。

利点と課題

ビジュアルプログラミング言語は、コンピュータープログラマーがコンピュータープログラムを開発するのに役立ちます（Menzies、2002）。

ネット要素と注釈が便利だと思う理由が少なくとも3つあります（利点は？）。

最初の理由。プロセスロジックは、一度に1つの要素を作成できます。これは、既存のネットに要素を追加することでネットを拡張できることを意味します（Petri、1966）。たとえば、コントローラのモデルは、内部コンポーネントと外部コンポーネントに分割できます。内部コンポーネントはシステムを調整します。外部コンポーネントは、環境からの入力を受け入れることにより、環境と連動します。図1は、内部コンポーネントのペトリネットモデルです。適切な場所とトランジションを追加することにより、外部コンポーネントのペトリネットモデルを内部コンポーネントのペトリネットモデルに追加できます（図2）。

図1コントローラーの内部コンポーネントのペトリネットモデル（Halloway、Krogh and Giua、1997）

図2コントローラーの内部および外部コンポーネントのペトリネットモデル（Halloway、Krogh and Giua、1997）

第二の理由。各ネット要素に関連付けられたコードは、複数の「プログラミング言語」から取得できます（Petri、1973）。JavaScript、COBOL、ADA、アセンブリ言語などのコンピューター言語から取得できます。それらは代数記号などの数学言語に由来します。これらは、英語、ドイツ語、フランス語、ギリシャ語、タガログ語、中国語などでエンコードされた散文から取得できます。したがって、ソフトウェアまたはシステム開発ライフサイクル全体のコミュニケーションとコラボレーションの基盤として使用できます。そして、異なるユーザー、開発者、利害関係者の間で（Petri、1973）。

第三の理由。ネット内の特定のグラフィックスオブジェクトに焦点を当て、関連するグラフィックスオブジェクトのコードまたはロジックアノテーションを書き出すことができます。図3のカードゲームのペトリネットモデルについて考えます。入力P7T4の矢印がプレース/遷移ネットの入力の標準グラフィックであり、m_7がプレースP7のマークである場合、入力場所のマークの更新はm_7 = m_7-1です。s_9 ^-が入力のステータスである場合、入力のステータスを更新するための論理注釈はs_9 ^-=（（m_7 <1）？false：true）です。

図3カードゲームのペトリネットモデル

ペトリネットの適用が難しいと思う理由が少なくとも3つあります（欠点は？）

グラフィックスオブジェクトが多すぎる場合、ネットの作成や読み取りが困難になります。難易度は、グラフィックのサブセットを取得し、1つ、2つ、または3つのグラフィックシンボルを使用して表現することで軽減できます（Noe、1973; Petri、1966）。たとえば、図3のカードゲームのペトリネットモデルの図にグラフィックオブジェクトが多すぎると考えられる場合、図の一部を組み合わせても、図をコンピュータープログラムにマップするのに十分な情報を維持できます。図4に、高レベルのグラフィックスを備えた図3にある同じゲームのペトリネットモデルを検討してください（Chionglo、2016a）。

図4高レベルグラフィックスを使用したカードゲームのペトリネットモデル（Chionglo、2016a）

別の例では、図2のコントローラーの外部コンポーネントを組み合わせて、図5に示すようなより簡潔なグラフィック表現を作成できます。

図5外部コンポーネント用の高レベルグラフィックスを備えたコントローラーのペトリネットモデル

最後に、相互に排他的な一連の場所または相互に排他的な一連の遷移も、高レベルのグラフィックスオブジェクトを使用して表すことができます（Chionglo、2015年）。

第二の理由。標準のグラフィックスであっても、特に最終的なダイアグラムがユーザーフレンドリーまたはリーダーフレンドリーであることを期待する場合、グラフィックスを描画して配置するのは難しい場合があります。ユーザーまたは読みやすい図を作成するための決定には、グラフィックスオブジェクトの適切なレイアウト、キャンバスと形状の適切な寸法、矢印の曲率、矢印の種類、テキストのサイズとフォント、グラフィックとテキストの色の選択。

第三の理由。すべての注釈はネット要素に直接または間接的に関連付けられているため、ネット要素の注釈を整然と作成するのは簡単です。ただし、すべての注釈をすべてのネット要素のグラフィックスとともに表示することは、ダイアグラムに表示される情報が多すぎる可能性があるため、良いアイデアとは言えません。たとえば、すべてのプロパティと論理注釈への参照を含む論理回路のペトリネットモデルの図を考えてみましょう（図6）。[元のモデルには、すべての出力のステータスのテスト条件が含まれていました（（Petri、1966）の78ページの図31）。テスト条件は、指定された初期マーキングの元のモデルと同等であるため、ここでは省略されました。したがって、すべての出力には、出力場所のマークを計算するための1つの論理注釈があります。]

図6注釈付きのプレイス/トランジションネット-ペトリの論文（1966）の英訳の図31ページ78に基づく

この課題を軽減する1つの方法は、モデルで使用される注釈のタイプを識別し、これらのタイプの注釈を含むグラフィックスオブジェクトを定義することです（Petri、1966）。したがって、ペトリネットダイアグラムが定義のグラフィックスオブジェクトで構成されている場合、これらのオブジェクトの解釈には「見えない」注釈を含める必要があります。図7は、標準ペトリネットとして解釈する必要があります（定義については、標準ペトリネットの注釈を参照してください）。したがって、論理注釈は図から省略できます。

図7プレイス/トランジションネット-ペトリ論文（1966年）の英訳の図31ページ78に基づく

この課題を緩和する別の方法は、注釈のフォームビューを使用して、図を補完または補足することです（Chionglo、2016b; 2014）。ビューはさらに小さなビューに分割でき、各ビューは表示および非表示にできます。

参照資料

JF Chionglo（2016a）。Stack Overflowの「React / Redux Flashcardゲームの状態フローを設計する方法」への返信。https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflowで入手できます。

JF Chionglo（2016b）。ペトリネットの2つのフォームビュー。http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdfで入手できます。

JF Chionglo（2015）。高レベルのグラフィックスを使用して、ペトリネット図のネット要素グラフィックスの数を減らします。http://www.aespen.ca/AEnswers/WjTpY1429533268で入手できます。

JF Chionglo（2014）。コンピュータプログラミングのネット要素と注釈：PDFでの計算と相互作用。https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDFで入手できます。

ハロウェイ、LE; Krogh、BH and Giua、A.（1997）。制御された離散イベントシステムのペトリネット手法の調査[電子版]。離散イベント動的システム：理論と応用、Vol。7.ボストン：Kluwer Academic Publishers、pp。151 – 190。

メンジーズ、T。（2002）。ビジュアルプログラミング言語の評価の問題。SKチャン（エド）。ソフトウェア工学と知識工学ハンドブック、Vol。2新興テクノロジー。世界科学出版社 Pte。Ltd.、pp。93 – 101。

Noe、JD、Nutt、GJ（1973）。「並列システムの表現のためのマクロE-Net」、IEEE Transactions on Computers、vol。C-22、No。8、1973年8月、718〜727ページ。

ペトリ、カリフォルニア（1973）。ネット理論の概念。コンピュータサイエンスの数学的基礎：Proc。シンポジウムとサマースクール、ハイタトラ、1973年9月3日〜8日、137〜146ページ。数学。研究所 スロバキアのAcadの。1973年の科学。

ペトリ、カリフォルニア（1966）。Automotaとの通信[trans。CFグリーン、ジュニア]。テクニカルレポートRADC-TR-65-377の補足I（ボリュームI）。グリフィス空軍基地、ニューヨーク：ローマ航空開発センター、研究技術部、空軍システム司令部、グリフィス空軍基地。http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdfから2011年8月31日取得。

ジョーンパーシバルハックワース：

ビジュアルプログラミングには何の問題もありませんが、ほとんどのタスクには適切なアプローチではない可能性があります。

おそらく、これまでのビジュアルプログラミング言語は未熟すぎたのでしょうか。高度な視覚化はソフトウェア成果物に適用できず、各開発者が独自に展開する「想像力」に完全に委ねられているという概念は、誤った仮定である可能性があります。低レベルの抽象化と高い実行パフォーマンスを実行する能力が犠牲にならない限り、統一された自動化された方法で抽象化のレベルを上げることは明らかです。これは最終的に、ドメインエキスパートの「プログラミング」につながる可能性があり、スプレッドシートがCOBOLプログラマのタスクを自動化して数値を操作する方法と大差ありません。ここでの主な違いは、数値を「一般的なシステム」の操作に置き換えることです。

コーディングテクノロジなしのプログラミング（PWCT）を見ることができます。

PWCTは、コードを記述する代わりにインタラクティブなステップを生成することにより、システムとアプリケーションの開発を可能にする汎用の視覚プログラミング言語です。

ここから始めるのが良い場所であり、オープンソースです。

トリッキーな質問。視覚的またはフローベースのプログラミングは実際に使用されるようになりましたが、すべてのプログラミング言語と比較して広く使用されているわけではありません。重要な要因は、メンテナンスと標準化です。コンピューターコードはページに印刷できます。視覚的なプログラムを印刷する方法は必ずしも明確ではありません。

現在のトップの答えとは対照的に、視覚的プログラミングの能力とテキスト言語には固有の理論的な制限は絶対にないと断言します。実際、視覚プログラミングは、抽象化の多くの層のより速い人間の概念化に基づいて、いつか維持するのが容易であると見られるかもしれません。そのため、その取り込みには、社会的/文化的inertia性/保守主義の紛れもない要素があるようです。

ビジュアルエディターはおそらくコードがはるかに複雑です。これは、テキストベースのIDEだけでも非常に複雑になる可能性があることを考慮すると、Eclipseのように非常に複雑です GUI構築のためのビジュアルプログラミングは現在かなり普及しています。

視覚的なプログラミングの使用は特定の領域で増加しており、これからずっと一般的になる可能性があるように思えます。

ビジュアルプログラミングは何十年もの間EE チップデザインに固有のものであり、抽象化ではなく、（サブ）システムが意図したとおりに2Dデザインでレイアウトされることを忘れないでください。

レゴマインドストームキットは、現在広く普及しており、10年以上前に、ビジュアルプログラミングに基づいた開発ソフトウェアが常にあり、多くのバージョンで大幅に合理化されました。

これは、歴史と展望を分析し、Webベースのプログラミングでより一般的になる可能性があることを示唆する興味深い最近の記事です。ページ上のコントロール/ウィジェットを動的にレイアウトすることは、視覚ベースのプログラミングの一種です。

多くのツールで広く使用されているもう1つの重要な領域は、ビジネスプロセスモデリングであるBPMです。

• 1970年代の銀行ソフトウェアからの不可解なコーディング方法が、どこでもWeb開発者の健全性をどのように保存できるか（Fast Company）

• BPM、ビジネスプロセスモデリングウィキペディア

これらのソリューションがあまり人気がない理由は、ほとんどの場合、管理が困難で混乱を招く可能性があるためです。

現在入手可能なビジュアルプログラミングツールのほとんどは、より大きなアプリケーションの一部であり、特定の目的に使用されています（例：UE4のブループリント）。

とにかく、最近私が一般的なプログラミングで出会った新しいものはKordueneです。これは、Windowsアプリケーションを作成するためのものであるため、実際にはあまり一般的な目的ではありません。

プログラムがテキストだと言うとき、@ Raphaelと他の人は間違っていると思います。そうではありません。それは多くのことです。コンピューターに何をするか、またはどのように行うかを指示しています。（非アクティブ、宣言型プログラミング）プログラミングとテキスト編集の関連付けは、歴史的で直感に反する教義です。初期のコンピューターの限られたテキスト入力/出力によって作成されました。人々はテキストパーサーではありません！

完全に視覚的な言語（要素をマウスなどで接続することで視覚的に何かをする場所）は汎用言語には実用的ではないと人々は正しいと思いますが、現在のすべての言語は中間言語に移行できるし、移行すべきだと思いますレベル。言語要素に視覚的表現がある場合、それはバイナリ言語ファイルに保存されます。プログラマーは、狂ったようにテキストを入力したり、線とインデントの呪文の下に住んだりしません。

しかし、ホットキー/コマンド/ UI要素の最も生産的な組み合わせを介して要素を挿入します。そして、文字列およびその他のデータと識別子のみを入力します。これにより、構文エラーが不可能になり、安全性と正確性を念頭に置いた言語（例：ADA）の生産性が向上します。また、一般的なエラーのクラス全体を不可能にすることにより、他の人をより安全でバグの少ないものにします。（ADAが面倒になることで防止するなど）

ある程度まで物事はこの方向に向かっていた。自動インデントと構文の色分けによる。悲しいことに、それが「人間のテキストパーサー」のコアコンセプトであることが間違っていることに気づいていませんでした。emacs vs vim引数は、どちらも間違っているためおかしいです。それらは、人為的に作成された問題の「解決策」です。