為什麼說視覺化程式設計是糟糕的想法？
視覺化程式語言可以讓程式設計師通過操縱圖形元素來建立程式，而無需鍵入文字命令。
眾所周知的例子是 Scratch，這是一種麻省理工學院開發的視覺化程式語言，用來教孩子們學程式設計。
該語言的優勢在於新手和普通使用者可以更容易接觸程式設計。二十世紀九十年代曾經有一種非常流行的運動，即通過所謂的 CASE 工具將這類工具帶入企業，這些企業的系統可以通過 UML 進定義和生成，而無需僱傭訓練有素的軟體開發人員。
這涉及“round tripping”的概念，即通過視覺化的手法為系統建模，根據模型生成程式程式碼，而且任何程式碼的變更都可以反向反映到模型上。但最終這些工具未能兌現承諾，而且大多數這類嘗試現在也已基本放棄了。
因此，除了一些非常有限的領域外，視覺化程式設計都未能成功。其中的原因基本上可以歸於以下幾種對程式設計的誤解：
文字程式語言混淆了本質上很簡單的過程。
抽象和解耦是外圍問題，對程式設計的意義不大。
為支援程式設計而開發的工具並不重要。
誤解一：文字程式語言混淆了程式設計本質
第一個誤解認為軟體開發的門檻很高，因為文字程式語言混淆了程式設計的本質。Scratch 在教育學家中的流行就屬於這種誤解。
該觀點認為程式設計實際上非常簡單，我們只需通過清晰的圖形來表現，就可以大大降低建立和閱讀軟體所需的學習曲線和努力程度。
我認為這種誤解是因為有些人未能真正讀懂用標準的文字程式語言編寫的程式，並想象可以將程式轉換成盒子和箭頭等圖形元素。
如果你這樣做，很快就會發現一行程式碼經常需要對映到多個盒子上，一個簡單的程式包含數百行程式碼的情況是常態，因此這將轉化為成百上千個圖形元素。在頭腦中理解如此複雜的圖形往往比閱讀同等的文字更加困難。
在這個問題上，大多數視覺化程式語言的解決方案是使用“塊”來代表更為複雜的操作，從而可以讓每個視覺化元素都代表一大段文字程式碼。視覺化流程工具是罪魁禍首。
問題是我們需要在某個地方定義這些程式碼。於是，這就成了“屬性對話程式設計”。視覺化元素本身僅代表最高級別的程式流程，而大多數的工作是通過隱藏在盒子中的標準文字程式碼完成。這種做法釀成了現如今兩邊皆難堪的局面。一邊的文字程式語言沒有現代工具支援。
屬性對話程式設計通常是低配版的標準開發環境，而且你必須選擇特定的語言，通常是某種指令碼語言。而在另一邊，視覺化元素只能等待有經驗的程式設計師建立，而且只有通過閱讀底層的程式碼才能讀懂程式，所以大多數視覺化表現手法的優勢都喪失了。
視覺上的“程式碼”和文字程式碼之間存在著阻抗失配，而且程式設計師必須不斷在兩者之間來回切換，時間都浪費在滿足圖形程式設計工具的需求上，而不是解決手頭的問題。
誤解二：抽象和解耦是外圍問題
因此才有了第二個誤解，即抽象和解耦是外圍問題。視覺化程式設計假設大多數程式都是簡單的程式序列，有點像流程圖。實際上，這也是大多數新手程式設計師想象的軟體工作原理。
然而，一旦程式的規模超出了簡單的示例，新手程式設計師很快就會被複雜性壓垮。他們發現很難推斷程式的程式碼庫，而且常常難以大規模地建立穩定又高效的軟體。
程式語言中的大多數創新都是為了管理複雜性，最常見的是通過抽象、封裝和解耦。面向物件和函數語言程式設計中所有型別的系統和裝置實際上都是為了努力控制這種複雜性。大多數專業程式設計師會持續不斷地抽象和解耦程式碼。
實際上，好程式碼和差程式碼之間的本質區別也在於此。視覺化程式設計工具很少擁有有效的機制來執行這些操作，而開發人員也必將陷入二十世紀七十年代 BASIC 的漩渦中。
誤解三：為支援程式設計而開發的工具並不重要
最後一個誤解是即使沒有現代程式設計工具的支援，視覺化程式設計師也可以程式設計。想想程式碼編輯器和 IDE 漫長的演變過程。
例如，Visual Studio 支援高效的智慧感知，可以單獨查詢基類庫中數千個 API。缺乏良好的原始碼控制是絕大多數視覺化程式設計工具的另一個主要的缺點。即使這些視覺化工具的佈局儲存為文字的格式，程式碼的差異也毫無可讀性可言，因此毫無意義。
我們很難從大塊的 XML 或 JSON 找出每行程式碼的修改來源。一些對程式的功能執行沒有任何影響的因素，比如圖形元素的位置和大小，也會導致元資料的變化，這讓解析差異變得更加困難。
文字程式語言知道將不同的程式碼儲存到不同的原始碼檔案中，因此係統某一部分的變更很容易與另一部分的變更合併。
視覺化程式設計工具通常會將每個圖表儲存在一個檔案中，這意味著合併也會成問題，當遇到難以解析差異的語義時，難度會更大。
總之，視覺化程式設計工具提供的優勢，即簡化程式的建立和理解只是一個海市蜃樓。
只有在非常簡單的程式設計中才可行，在這種不理想的形勢下，最好的結果也不過是說：視覺化元素是具有混淆副作用的文字程式碼的容器。
補充說明
可能在第一段中加上 Scratch 的截圖並用作主要示例是錯誤的做法。我不是一名教育工作者，我不知道 Scratch 是否可以作為一種有效的教學工具。
許多人提到，Scratch 在程式設計教學方面非常有用，特別是對兒童而言。任何可以引導人們進入精彩紛呈的程式設計世界的東西，我都歡迎。
我並不想通過這篇文章抨擊 Scratch，提到它只是因為它是大多數人都聽過的最有名的視覺化程式設計系統。
有人在 Reddit 上提到的另一個反面例子是靜態結構工具，例如 UI 設計工具、資料庫模式設計工具或類設計工具。
我同意這些工具非常有用。任何有助於視覺化資料結構、或程式的大規模結構的工具都是好東西。
但這些不足以支撐他們的論點。PowerBuilder 等 90 個試圖通過在圖形視覺化之上構建工具，來開發出一個完全不用寫程式碼的開發環境，可是最終都失敗了，這恰恰證明了我的觀點。
你如何看待視覺化程式設計？
針對視覺化程式設計並不是理想的想法，評論區的不少網友也發表了不一樣的看法：
評論1：
你混淆了圖形資料流語言（帶有隱藏選項框和連線這些框的箭頭）與Scratch。Scratch 是一種文字語言，裡面的程式語句和型別是預定義的形狀，可以消除語法錯誤。
你無法在 Scratch 中犯語法錯誤，因為這些框無法組合在一起。 除了這種語法幫助之外，Scratch 不會隱藏任何內容，並且格式也與純文字語言沒有差別。
也就是說，我同意你說的有關其他教學語言的大部分內容，例如用於 Lego Mindstorms 機器人套件的語言。
該語言源自 LabView，大多數初學者發現很難超越幾個塊或連線變數之類的東西。我的猜測是，一種能夠通過變數賦值來達到複雜性障礙的語言並不能很好地擴充套件:-)。
評論 2：
我認為你的文章的出發點不正確，因為視覺化程式設計根本不是為程式設計師準備的。
對此，你怎麼看？歡迎下方留言，分享你的看法！
原文：http://mikehadlow.blogspot.com/2018/10/visual-programming-why-its-bad-idea.html
作者：CODE RANT
譯者：彎月，責編：屠敏
【End】
推薦閱讀：
點選“閱讀原文”，開啟 APP 閱讀更順暢。