ビジュアルプログラミングが成功しなかった理由と、将来のパラダイムがそれを変える可能性があるのはなぜですか。
Android、iOS、約束されたWindows 8などの「ビジュアル」OSの数がますます人気になっているため、新しいビジュアルが不足している可能性があるため、プログラマーがこれらの新しいテクノロジーを使用してコーディングする新しい方法を持っているとは思えませんプログラミング言語のパラダイム。
現在のコーディング開発環境と、Windows 8からの新しいOSアプローチとの非互換性について、いくつかの議論を見てきました。Androidと他のタブレットOSのことです。つまり、今日、新しいタブレットがあれば、たとえば、コーディングアシスタントが数千行のコードを「書き込む」ことを想定していないため、外部キーボードを使用することはコーディングの要件のほとんどです（タッチスクリーンを使用してプログラムするのは非常に難しいようです）。 。
それでは、「新しい」ビジュアルプログラミング言語のパラダイムはどの程度高度なのでしょうか。これらの新しいパラダイムにはどのような特性が必要ですか？
利用できるビジュアルプログラミングツールはいくつかありますが、私が知っている限りでは、それらはすべて恐ろしいものです。
基本的に宣言型の視覚言語であるUMLは、全体像を表現するのに優れていますが、実装の詳細を具体化すると、すぐに圧倒されて混乱します。基本的なビルディングブロックを回路図によく似たものに結合してコードを作成できるプログラミング環境がいくつかありますが、UML（またはそれ以上）のように、そのような図はすぐに混乱します。 Visual Studio、NetBeans、Eclipse、そしておそらく他の多くのIDEには、Webページやダイアログなどのビジュアルデザイナーが含まれており、それらはほとんど機能しますが、驚くほどの品質にもかかわらず、完全にデザイナーモードでアプリケーションを構築することは依然として非現実的です-テキストモードは、最終的にはより多くの制御を提供します。
重要な理由は、プログラマーが究極のパワーユーザーであることです。グラフィカルインターフェイス学習曲線が浅いExcel。それらの直感的なインターフェースは、それらを使い始めるのを容易にしますが、それらを使用するために必要な手と目の調整、および必須の視覚的フィードバックループ（どこにあるか見ることができない限り、何かをクリックすることはできません）は、最大値を多少制限します入力速度と完全にキーボード駆動のシステムの比較：物理的なキーは移動しないため、キーを押したときに予期される応答が期待できるため、遅いsshターミナルセッションに入力しても、すぐにフィードバックなしで入力を続けることができます。
もう1つの理由は、ソースコードに含まれる意味に多くの重複するレベルがあるためです。典型的なOOPプロジェクトでは、基本的にツリー構造であるクラス階層があり、階層を介した相互参照を実装するインターフェースがあります。コードフローがあります。巨大なフローチャートを想像して、そのレイヤーの複雑さについてのアイデアです。次に、データ構造もあり、これもコードに埋め込まれています-ツリー、リスト、Key-Valueコレクション、循環リスト、ハッシュマップなど。スレッドを使用している場合は、さらに別のレベルの意味。テキストのソースコードを使用すると、同じコードを別の考え方で見て、個々のレベルを確認し、コードを別の方法で見るだけで拡大/縮小できます。グラフィカルなプログラミングツールでは、次のように切り替える必要があります。別のビュー-フロー、クラス階層、データ構造、およびスレッド関係を同時に含むグラフィック表現を想像することはできません。
そして、私たちのコードで使用するテキストベースのツールの巨大なバッテリーがあります：テキストベースの検索と置換、差分、バージョン管理、静的コード分析、コピーと貼り付け（これはします用途があります（例：リファクタリング）、コードジェネレータなど。また、コードを電子メールに埋め込んだり、コードのチャンクをバグトラッカーにコピーして貼り付けたりすることも簡単です。基本的に、すべてのコードファイルをテキストファイルにすることで、現在および将来のプログラミング言語で記述されたコードで何十年もの間完成されてきた戦闘強化ツールを使用できます。
意味のある注意点：タブレットを真剣に使用してコードを書いていますか？本当に？私はそれを嫌うでしょう。私は常に、人々が強力なデスクトップを使用してコードを作成し、それに接続されたタブレットを使用してコードを実行すると想定していました。
映画について考えてください。これは芸術の中で最も「視覚的な」媒体であり、色、動き、3Dなどが含まれます。
次に、それらがどのように作成されるかを考えます。誰もがスクリプトから作業します。図面やセットデザインが添付されている場合がございます。しかし、それは台本から始まり、日々の撮影は台本によって決定されます。
言語とテキストは信じられないほど強力で表現力豊かなツールであり、視覚的なツールは説明、説明、簡略化に適していますが、正確な制御が欠けていると扱いにくくなります。また、複雑な図で何が起こっているのかを、適切に整理されたテキストを使用した場合よりもはるかに迅速に失います。
データウェアハウススペースでは、ETLに「ビジュアル」開発環境を使用するのが一般的です。これは単純なことをより単純にしますが、複雑なものを実装するのは悪夢です。影響分析のようなことはひどく難しくなり、ソースコード管理はほとんど不可能です-何かが変わったのはわかっていますが、何が「違いを見つける」パズルになるかを見つけます。
ビジュアルプログラマーへの注意-私はそう言った！ 80年代の初めにビジュアルプログラミングの試みについて話を聞いたところ、ジオメトリの歴史はそれほど厳密ではない、または明確に定義されたビジュアル表現から正確なテキストによる議論までの2000年の進歩であり、その時点で物事を適切に証明できるようになりました。 UMLや他の多くのビジュアルモデリング言語は、実際には基礎となるネットワークまたはテキストデータのビジュアル表現にすぎないことに注意してください。厳密に言えば、厳密な意味を定義できます。
私は1つの非標準表記「Parnas Tables」に感銘を受けましたが、これらは実際にはコードよりも視覚的です。
私はグラフィカルプログラミングについて少し経験がありますが、その経験の大部分は悪いものでした。これらのシステムのほとんどは単純なフローチャートシステムであり、非常に単純なシステムで作業する場合は問題ありません。また、グラフィカルエディターを備えたデータ変換ツールも使用しました（基本的には構文のないXSLT）。繰り返しますが、非常に単純な変換では問題ありませんでしたが、実際の変換では使用できませんでした。
これらのシステムではほとんど考慮されない考慮事項があります。
- 最近のほとんどのプログラムは同時進行であり、調整された状態変更のために言語のメカニズムに依存しています。ほとんどのフローチャート作成ツールには、同時計算を整理するメカニズムがありません。例外は実装 [〜＃〜] bpmn [〜＃〜] です。これは、プロセス計算の強力な理論的基盤を持つBPMLのグラフィック表記です。 BPMLはパイ計算の完全な実装を目的としていますが、その採用は弱いものですが、BPELと呼ばれる縮退バージョンがWSスタックの一部として人気を博しています。
- 例外処理はフローチャートシステムでも弱い傾向があります-複雑なソフトウェアには優れた例外処理が必要です。
しかし、機能が不足していることを除けば、私が使用したグラフィカルプログラミングシステムは、操作するのが面倒でした。混乱する前に、一度に12個以上の要素を画面に収めることは困難です。あなたは常にマウスからキーボードへ、そして戻って移動しています。構文の強調表示とオートコンプリートを備えたテキストエディターでのコーディングは、ほんの少しの時間で済みます。
「LabView以来、まったく進展がなかったと思います。」
ここでの他の投稿と一緒に良い観察ですが、ビジュアル（グラフィカル）プログラミングパラダイムの可能性は、過去数十年にわたって表面を傷つけただけです。新しいコンピュータサイエンスは、多くの欠点を克服しつつ、ソフトウェアシステムの開発、特に新興の並列プログラミングドメイン空間において、私たちの強力なパターンマッチング機能を真に利用する可能性を提供しています。この新しい科学はキュビコンと呼ばれています。このテクノロジーの概念的な説明は次のとおりです。
アイコン式はCubicon発明を形成しますが、メタオブジェクト表現Cubiconイノベーションを形成し、フォームと機能を1つの媒体として融合します。 Cubiconの開発は自己完結型でした。これは、従来のプログラミング手法ではもはや十分な進歩がもたらされていないという前提に基づいていました。 Cubiconは、構文、セマンティクス、およびコンテキストの語彙を構成する各言語構成要素を受け取り、それらのすべての従来の使用法を新しい表現でグラフィック表示に置き換えます。要するに、Cubiconは完全に新しいグラフィカル言語であり、プログラミングの世界を新たに見る方法であり、明確に定義されたグラフィカル代数です。グラフィカルなイノベーションとして、Cubiconは、フレームワーク、オブジェクトとその周囲の融合、およびキューブ内の言語要素として表現されたオブジェクトの複数のビューの組み合わせの観点から、プログラムの構築をサポートしています。この概念的なアプローチは、相互作用する視点として整理された単純な幾何学的形態の選択に自然につながりました。このプログラミングへのアプローチの価値は、言語要素の表現だけでなく、その構成から生まれるダイナミズム、つまり完全に制御されているものにもあります。
ソフトウェア開発の「芸術」は、Cubiconの幅広い採用により、より迅速に真の「科学」に進化できます。その科学は、「単語」と「方程式」の管理を超えた3番目の「キラーアプリ」カテゴリにつながる可能性があります。個人の個人的に開発する能力で、人口の幅広い層に力を与え、一般的なシステムを管理します。この理論は、そのコンポーネントの相互作用とそれらの相互作用の非線形性によってシステムを特徴付けます。
プログラミングにおけるcat、mammal、animal分類法などの抽象化の表現言語の単語は、一般的なシステムでは文脈の感覚を伝えません。直感的なグラフィック抽象化により、「写真は千の言葉に値する」ことができます。 Cubiconは、基本的な人間の能力を活用して、共有可能なメンタルキューブモデルとして 一般システム の表現で空間情報を効果的に処理します。 Cubiconは複数のパラダイム言語であり、ドメインエキスパートが複雑なプログラム構造と振る舞いを、完全に構文駆動型で意味論的にバインドされた宣言型環境で表現できるため、基盤となる計算エンジンを電子スプレッドシートのように効果的に抽象化できます。
キューブモデルには、複数のスキーマとして表される7つの主要な視点があります。
トピックマップ-トピックとその関連のグラフ基板
Genealogy-概念とテンプレートのオントロジースキーマ
Composition-コレクション間のスキーマ全体
Network-メッセージを運ぶオブジェクト間のリンク
Collaboration-すべてのソフトウェアコンポーネントと他のコミュニティとの依存関係のディレクトリ
Image-グラフィカルユーザーインターフェイス
Behavior（cube center）-プロセスフロー、制御フロー、および有限状態マシン（FSM）
Cubicon IDEには、没入型環境内で人間の意図をキャプチャ、マッピング、および実行するために集合的に使用される追加のパースペクティブも含まれています。一般的なシステムは高解像度でシミュレートでき、選択した言語要素を複数の観点から即座に表示できます。システム要件が時間とともに変化しても、再結合のために常に機敏性を保ちます。
宣言型プログラミングは、長年にわたって多くのグラフィカルデータフローベースの言語を通じて適用されてきました。これらの言語は、「ワイヤー」を介して接続できる上位レベルの抽象化アイコンに、事前にパッケージ化された「何」の動作を提供します。このアプローチの課題は、ソース組織があらゆるタイプの可能なユースケースをカバーするアイコンタイプの急増をサポートする必要があることです。アイコンの「動作」動作をカスタマイズするために開発者コミュニティに負担をかけるには、初心者がアイコンをスクリプト言語に分解する必要があります。したがって、このアプローチは、このはるかに制約の少ないテキスト表現からドメインエキスパートを保護する宣言的アプローチの本来の目的に反します。スプレッドシートのような同等の宣言的アプローチに到達するには、一般的なシステムのプログラミングで使用するための別のアプローチが必要です。
「方法」を抽象化する代わりに、Cubiconの開発における拡張された応用研究作業は、命令型プログラミングを完全に自動化するタスクに取り組みました。これは、マイクロマシンベースの言語が効果的なソリューションであった場所です。これにより、ドメインの専門家は高度に自動化された環境で複雑なロジックを表現できます。 Cubiconは、宣言型の言語スタイルを、制御フローを介して、有限状態マシン（FSM）レベルの抽象化にプッシュします。リアルタイム実行は、周囲環境との決定論的な相互作用を保証する同期反応計算モデル（MoC）の下で実行されます。ロケットサイエンスではなく、一般的なシステムを構成する抽象概念を分解することによって実行される徹底的なメタデザインであり、基本的にはミステリーを低レベルのプログラミング「ギアとスプリング」での作業から取り除きます。