ご注意
この出版物の最初のバージョンは、300を超えるコメントの形でRedditに大きな反応を示しました。 その後、受け取った多くの人からの批判に答えるために、小さな更新を追加することにしました。
ビジュアルプログラミング言語は、テキストコマンドを入力するのではなく、グラフィック要素を操作することでプログラマがプログラムを作成できるようにする言語です。 有名な例は、子供の教育に使用されるMITネイティブの視覚プログラミング言語であるScratchです。 その利点は、プログラミングが初心者と非プログラマーによりアクセスしやすくなることです。
1990年代には、いわゆるCASEツールを使用してビジュアルプログラミングを企業環境に導入するという非常に人気のある動きがありました。 これは、システムを視覚的にモデル化し、結果のモデルからプログラムコードを生成し、コードの変更をモデルに戻すことができる「ラウンドトリップ」の概念によるものです。 残念ながら、そのようなツールは使命を果たすことができず、[実装に関する]実験の大部分は現在ほとんど放棄されています。
したがって、一部の非常に限られた領域を除いて、ビジュアルプログラミングは人気を得ていません。 この状況は、主にプログラミングに関する次の誤解によるものです。
- テキストプログラミング言語は、本質的に単純なプロセスを混乱させます。
- 抽象化とデカップリング（ デカップリング、接続性の低下 ）は、プログラミングで小さな周辺的な役割を果たします。
- プログラミングを支援するために設計されたツールは重要ではありません。
最初の誤解は、テキストプログラミング言語がプログラミングの本質を複雑にしているため、ソフトウェア開発は参入のしきい値が高いと主張しています。 アカデミックな教育者の間でのスクラッチの人気は、この誤解と相まって遊んでいます。 アイデアは、プログラミングは実際には非常に単純であり、明確なグラフィック形式でしか想像できない場合、プログラムコードの作成と読み取りに必要な学習曲線と精神的な労力を大幅に削減することです。
このエラーは、標準のテキストプログラミング言語で書かれた典型的なプログラムを実際に読むことができず、「立方体」や矢印からグラフィック要素に変換される方法を想像できないことに起因すると思います。 それでもこれを想像できる場合は、1行のコードが複数の「ブロック」としばしば一致することがすぐに明らかになります。 最も単純なプログラムであっても、数百行または2行のコードが存在することは珍しいことではないため、そのコードは数百または数千ものグラフィック要素に変わります。 このような複雑な画像を精神的に解析する試みは、同等のプログラムテキストを読むよりもはるかに困難です。
ほとんどのビジュアルプログラミング言語の解決策は、「ブロック」をより複雑にして、各ビジュアル要素がテキストコードの大きなブロックと同等になるようにすることです。 ワークフローの視覚的なツールは、すぐに障害になります。
問題は、コードをどこかで定義する必要があることです。 したがって、[大きな視覚要素の]コーディングプロセスは「ダイアログのプロパティのプログラミング」に変わります。 視覚要素自体は、実行中の最高レベルのプログラムの動きのみを表し、ほとんどの作業は視覚的な「キューブ」に隠された標準のテキストコードで行われます。 その結果、私たちは両方の世界で最悪の事態に対処し、最新のツールでサポートされていないテキストプログラミングを取得しました。
通常、プロパティのダイアログは非標準の開発環境であり、特定の言語、通常は何らかのタイプのスクリプト言語を選択します。 基本的な視覚要素自体は、経験豊富なプログラマーのみが作成でき、基本的なコードを読むことによってのみ完全に理解できるため、視覚的なプレゼンテーションの利点のほとんどはここでは失われます。
視覚的な「コード」とテキストコード（ 一連の概念的および技術的な問題 ）の間にインピーダンスの不一致があり、プログラマーはそれらの間のインターフェイスをナビゲートする必要があり、多くの場合、元のタスク（プログラムの作成）を解決するよりもグラフィカルプログラミングツール自体の改善により多くの労力を費やします。
そして今、私たちは、抽象化と重複排除がプログラミングで小さな役割を果たしているという2番目の誤解に至ります。 ビジュアルプログラミングは、ほとんどのプログラムがフローチャートに似た単純な手続き型シーケンスであるという前提に基づいています。 原則として、ほとんどの初心者プログラマーは、ソフトウェアはそのように機能すると考えています。
ただし、プログラムがかなり単純な例以上のものになると、その複雑さはすぐに初心者プログラマを圧倒します。 初心者は、大規模な手続き型コードベースについて話すのが非常に難しく、安定した効率的な大規模ソフトウェアを作成しようとするたびに行き詰まってしまいます。 プログラミング言語の主な革新は、通常、抽象化、カプセル化、および接続性の削減を通じて、複雑さを管理する試みでした。 すべての型システムとオブジェクト指向および関数型プログラミング言語の構築は、実際にはこれらの言語の複雑さを制御しようとするだけの試みです。
ほとんどのプロのプログラマーは、常にコードを抽象化し、分離します。 実際、良いコードと悪いコードの違いは、基本的にプログラマーがどれだけこれを行うことができるかです。 ビジュアルプログラミングツールがそのようなことに対して効果的なメカニズムを持つことはめったにありません。その結果、「ビジュアル」開発者は利用可能な機能に閉じ込められ、1970年代のBASICに相当します。
最後の誤解は、ビジュアルプログラマーは、数十年にわたって開発されてきたすべてのプログラミングサポートツールがなくても実行できると考えられていることです。 コードエディタとIDEの長い進化を見てください。 たとえば、Visual Studioは、基本クラスライブラリだけで利用できる何千ものAPIを覗くことができる効果的なインテリセンスツールをサポートします。 優れたバージョン管理の欠如は、ほとんどのビジュアルプログラミングツールのもう1つの大きな欠陥です。
テキスト形式でレイアウトを保存しても、「差分」には意味がないか、ほとんど意味がありません。 XMLまたはJSONの大きなブロックで「非難」する（コミットを見つけ、特定の行を変更する責任がある）ことは非常に困難です。 グラフィック要素の位置やサイズなど、プログラムの機能的な実行に意味のないものは、常にメタデータの変更を引き起こし、diffの解析をさらに困難にします。
テキストプログラミング言語は、コードの構造ブロックを個別のソースファイルに分離することを学習しているため、システムのある部分の変更を別の部分の変更に簡単にマージできます。 ビジュアルツールは通常、「ファイルごとに1つの図」の原則に従って結果を保存します。つまり、マージが問題になり、「diff」のセマンティックな意味を分析するのが難しい場合はさらに困難になります。
更新する
スクラッチスクリーンショットを撮って、最初の段落の主要な例としてそれを使用したとき、私はおそらく誤解されていました。 私は教師ではなく、学習ツールとしてのScratchの有効性について自分の意見はありません。 多くの人は、特に子供向けのプログラミング教育に非常に役立つと言っています。 人々がプログラミングの素晴らしいエキサイティングな世界に入るのを助けるものはすべて称賛されるべきです。 私は今、特にScratchを批判するつもりはありませんでした。これは視覚プログラミングシステムの例に過ぎません。私にとっては、ほとんどの読者は少なくとも聞いたことがあるはずです。
Redditが提供するもう1つの反例は、UIデザイナー、データベーススキーマデザイナー、クラスデザイナーなどの静的構造ツールです。 私は彼らが非常に役立つことに同意します。 プログラムのデータ構造またはスケール構造を視覚化するのに役立つものはすべてボーナスです。 しかし、彼らは決して十分ではありません。 これは、コードを操作する必要なく開発環境を作成するためのグラフィカルな視覚化に基づいたPower Builderなど、90年代のツールが完全に失敗したことからも明らかです。
著者について：
ノート、大声で考え、わかりやすい目で学ぶ、誤解、間違い、希釈されていない意見。 私は説教開発者のマイク・ハドローです。 私はイングランドの南海岸のブライトンの近くに住んでいます。
翻訳は、プロのソフトウェア 開発およびテスト会社であるEDISON Softwareによってサポートされていました。