ビジュアルプログラミングとは、人間がイラストを使って処理を記述できるようにしたプログラミング言語の一種です。 典型的なテキストベースのプログラミング言語がプログラマをコンピュータのように考えさせるのに対し、ビジュアルプログラミング言語では、プログラマが人間にとって意味のある言葉でプロセスを記述することができます。 ある極端な例では、ツールは、人間の思考と、メモリの周りでビットをシャッフルするコンピュータとの間のギャップからプログラマをほぼ完全に保護します。 ビジュアルプログラミングツールでToDoリストを作成するために、プログラマはアプリのフローを描き出す。 出来上がったフローチャートには、画面やユーザーのインタラクション、各段階でデータがどうなるかが記述されています。
開発者として、テキスト ベースのプログラミング言語が実装に完全に焦点を合わせていることは承知しています。 確かに、より高度な言語や最新のフレームワークは、便利なショートカットを提供してくれます。 しかし、開発者の仕事は、人間のニーズをコンピュータの限られた能力に適合するプロセスに変換することです。
他のビジュアル コード化ツールは、テキスト ベースのプログラミングと同じプロセスとパラダイムに従っています。 クラスと、インスタンス化するオブジェクトとの関係を、テキスト エディタにすべて入力するのではなく、描画することを想像してください。 しかし、ビジュアル プログラマはどこにいるのだろうかと思うかもしれません。 なぜ私たちはいまだに手書きでコードを書いているのでしょうか。 ビジュアルプログラミングは悪いアイデアだということでしょうか。
これらの質問に答え、今日のビジュアル プログラミングの状況に飛び込む前に、ビジュアル プログラミングとは何か、それはどこから来たのか、どのように進化してきたのか、そしてなぜなのかについて理解する必要があります。
次世代のビジュアル開発ツールを発見する
A Brief History of Visual Programming Software
歴史が示すように、1990年代のビジュアル プログラミングはゲーム作成キット、マルチメディア ツール、データベースに限られていたと言ってよいわけではありません。 Rational Software (2003年に IBM に買収されました) は、1980年代半ばから、非 GUI の Ada IDE を構築していたのです。 さらに、彼らはソフトウェア開発プロセスの定義にも手をつけた。 Rational Unified Processとそれに関連する取り組みが、最終的にUnified Modelling Languageにつながったのですが、これはコードを一行も書かずにシステムの最後の部分まで文書化する可能性を持っていました。 これは、ビジュアルプログラミングのように見えますが、実行可能なソフトウェアを作成するものではありません。
UML は、オブジェクト指向のシステムを記述するための標準化された包括的な言語を提供しました。 しかし、UMLフィーバーは一部の建築家を襲いました。 The Pragmatic Programmer」の共著者である Andy Hunt は、あるソフトウェア プロジェクトで、アーキテクトがコードを 1 行も書く前に UML 図を作成することに 2 年間を費やしたという話をしています。 実行可能な UML は、その欠けている部分 (実行可能なソフトウェア) を追加する試みでした。 いくつかの実装が表面化しましたが、PHP、Ruby on Rails、およびその他の動的スクリプト言語に急速にフォーカスを移しつつあった世界に大きなインパクトを与えることはありませんでした。 Rational Rose は、UML を使用してソフトウェアを作成し、C++ や Java などのターゲット言語で実行可能なコードを生成するためのツール群です。 画像ソース Assignment Help
Back to the Future: 今日のビジュアル プログラミングの状況
歴史が示していることに基づいて、ビジュアル プログラミングは死んだのだろうかと疑問に思うかもしれません。 ビジュアルプログラミングの熱狂的なファンは、ビジュアルプログラミングはまだ死んでいないと言うでしょう。 ビジュアルプログラミングとは何か」と尋ねると、まず、無名のドメイン特化型ツールの名前を挙げるでしょう。 そして、そのツールこそがビジュアルプログラミングが生きている証拠だと言うでしょう。 その間、あなたは必死でGoogleで検索することになる。 その結果、彼らが挙げたツールについてだけでなく、そのツールが存在する高度に専門化した世界についても学ぶことができます。
ビジュアル プログラミングには、シンセサイザーをプログラミングしたり、UML マニアに達成感を与えたりと、間違いなくその役割があります。 しかし、汎用ソフトウェアでは、純粋に視覚的にモデル化するには、世界はあまりにも複雑です。 同様に、ビジュアルプログラミングソフトウェアは、汎用のテキストプログラミング言語の妨げにならない方法で、作成者の想像力によって制限される傾向があります。
Visual Basic、Delphi、およびそれらの子孫のようなツールは、ソフトウェアを視覚的に構築することが非常に効率的であることを私たちに教えてくれました。 ビジュアル プログラミング言語の新しい人生？
プログラミングの初期は、確かに大変でした。 しかし、一人の人間がそのソフトウェアを作るために必要なすべてのことを理解し、専門家になることができたのです。 古い人なら、1980年代のソフトのタイトルを思い返してください。 シド・マイヤー、ミッチ・ケーパー、ジェフ・ミンターは、有名なアプリケーションやゲームを独力で、あるいはせいぜい1人の協力者とともに作成し、あるレベルの名声を獲得しました。 当時は、ソフトウェアやハードウェアのアップグレードサイクルは何年もかかりました。 今日、私たちは「毎日新しいJavaScriptライブラリがある」と冗談を言っています。 しかし、現代のソフトウェア開発は、私たちの多くがついていけないようなペースで進んでいるという考えには真実があります。 初期の開発者がすべてを自分で行っていたのに対し、現代のソフトウェア開発チームには CI ツールを管理することだけが仕事の人が一人いるかもしれません。 開発者は、1つのフレームワークやプラットフォームに集中してキャリアを過ごします。iOS開発者はiOS開発者であり、モバイル開発者ではありません。 ウェブ開発者は、10年に一度か二度、好みのフレームワークを変えるかもしれません。 手動でアセンブリ言語を専門的に書いている人はほとんどいません。
ソフトウェアの範囲が変わったというだけではありません。 ある程度、開発者自身も変わってきています。 ソフトウェア・エンジニアは、最近では単なる職業のひとつに過ぎません。 数十年前までは、たとえば Amiga で成功したゲームの Atari ST への移植版を書くために、まったく新しいシステムを習得する献身的な人たちが抱く情熱でした。 しかし、それは理解できます。コンピューティングはもはやニッチではありません。
今日、ソフトウェア開発はますます複雑な部分で構成され、開発者は並外れた専門性を持つ普通の人々である、という世界になってきています。 その複雑さと専門性は、初期のツールの純粋なビジュアル プログラミングには不向きですが、丸みのあるソフトウェア エンジニアリング チームを構築することもますます難しくなっています。
純粋なビジュアル プログラミング環境が失敗した場所では、ビジュアル プログラミングの長所を取り入れ、それをテキスト ベースのコーディングと組み合わせた同様のツールの全キャッシュが存在します。 OutSystems のようなツールにより、開発者はインタラクション フロー、UI、およびオブジェクト間の関係を描くことによって視覚的にソフトウェアを作成できますが、より良い方法である場合には手書きのコードでそれを補うことができます。 ローコード プラットフォームはソフトウェア開発の複雑さを軽減し、すべての基礎技術を学ぶことなく、一人の開発者がリッチで複雑なシステムを作成できる世界に私たちを戻してくれます」
Next Generation of Visual Programming: 約束の実現」
ビジュアル プログラミングは非常に有望で、解決したかった問題がなくなったわけではありません。
しかし、現実世界の問題には、ビジュアル プログラミングが提供できるよりも大きな柔軟性が必要です。 ローコードはその約束を守り、現代のソフトウェア開発で見られる複雑さを軽減するために適用します。 ですから、「ビジュアル プログラミングとは何か」ではなく、「ローコードとは何か」を考えてみてください。 代わりに、”ローコードとは何か？”と問いかけてみてください。 また、オンラインデモを予約したり、OutSystemsを試用することもできます（無料です）。