可視化編程語言可以讓程序員通過操縱圖形元素來創(chuàng)建程序，而無需鍵入文本命令。

眾所周知的例子是 Scratch，這是一種麻省理工學(xué)院開發(fā)的可視化編程語言，用來教孩子們學(xué)編程。

該語言的優(yōu)勢在于新手和普通用戶可以更容易接觸編程。二十世紀九十年代曾經(jīng)有一種非常流行的運動，即通過所謂的 CASE 工具將這類工具帶入企業(yè)，這些企業(yè)的系統(tǒng)可以通過 UML 進定義和生成，而無需雇傭訓(xùn)練有素的軟件開發(fā)人員。

這涉及“round tripping”的概念，即通過可視化的手法為系統(tǒng)建模，根據(jù)模型生成程序代碼，而且任何代碼的變更都可以反向反映到模型上。但最終這些工具未能兌現(xiàn)承諾，而且大多數(shù)這類嘗試現(xiàn)在也已基本放棄了。

因此，除了一些非常有限的領(lǐng)域外，可視化編程都未能成功。其中的原因基本上可以歸于以下幾種對編程的誤解：

文本編程語言混淆了本質(zhì)上很簡單的過程。

抽象和解耦是外圍問題，對編程的意義不大。

為支持編程而開發(fā)的工具并不重要。

誤解一：文本編程語言混淆了編程本質(zhì)

第一個誤解認為軟件開發(fā)的門檻很高，因為文本編程語言混淆了編程的本質(zhì)。Scratch 在教育學(xué)家中的流行就屬于這種誤解。

該觀點認為編程實際上非常簡單，我們只需通過清晰的圖形來表現(xiàn)，就可以大大降低創(chuàng)建和閱讀軟件所需的學(xué)習(xí)曲線和努力程度。

我認為這種誤解是因為有些人未能真正讀懂用標準的文本編程語言編寫的程序，并想象可以將程序轉(zhuǎn)換成盒子和箭頭等圖形元素。

如果你這樣做，很快就會發(fā)現(xiàn)一行代碼經(jīng)常需要映射到多個盒子上，一個簡單的程序包含數(shù)百行代碼的情況是常態(tài)，因此這將轉(zhuǎn)化為成百上千個圖形元素。在頭腦中理解如此復(fù)雜的圖形往往比閱讀同等的文本更加困難。

在這個問題上，大多數(shù)可視化編程語言的解決方案是使用“塊”來代表更為復(fù)雜的操作，從而可以讓每個可視化元素都代表一大段文本代碼?？梢暬鞒坦ぞ呤亲锟準?。

問題是我們需要在某個地方定義這些代碼。于是，這就成了“屬性對話編程”?？梢暬乇旧韮H代表最高級別的程序流程，而大多數(shù)的工作是通過隱藏在盒子中的標準文本代碼完成。這種做法釀成了現(xiàn)如今兩邊皆難堪的局面。一邊的文本編程語言沒有現(xiàn)代工具支持。

屬性對話編程通常是低配版的標準開發(fā)環(huán)境，而且你必須選擇特定的語言，通常是某種腳本語言。而在另一邊，可視化元素只能等待有經(jīng)驗的程序員創(chuàng)建，而且只有通過閱讀底層的代碼才能讀懂程序，所以大多數(shù)視覺化表現(xiàn)手法的優(yōu)勢都喪失了。

視覺上的“代碼”和文本代碼之間存在著阻抗失配，而且程序員必須不斷在兩者之間來回切換，時間都浪費在滿足圖形編程工具的需求上，而不是解決手頭的問題。

誤解二：抽象和解耦是外圍問題

因此才有了第二個誤解，即抽象和解耦是外圍問題。可視化編程假設(shè)大多數(shù)程序都是簡單的程序序列，有點像流程圖。實際上，這也是大多數(shù)新手程序員想象的軟件工作原理。

然而，一旦程序的規(guī)模超出了簡單的示例，新手程序員很快就會被復(fù)雜性壓垮。他們發(fā)現(xiàn)很難推斷程序的代碼庫，而且常常難以大規(guī)模地創(chuàng)建穩(wěn)定又高效的軟件。

編程語言中的大多數(shù)創(chuàng)新都是為了管理復(fù)雜性，最常見的是通過抽象、封裝和解耦。面向?qū)ο蠛秃瘮?shù)式編程中所有類型的系統(tǒng)和裝置實際上都是為了努力控制這種復(fù)雜性。大多數(shù)專業(yè)程序員會持續(xù)不斷地抽象和解耦代碼。

實際上，好代碼和差代碼之間的本質(zhì)區(qū)別也在于此?？梢暬幊坦ぞ吆苌贀碛杏行У臋C制來執(zhí)行這些操作，而開發(fā)人員也必將陷入二十世紀七十年代 BASIC 的漩渦中。

誤解三：為支持編程而開發(fā)的工具并不重要

最后一個誤解是即使沒有現(xiàn)代編程工具的支持，可視化程序員也可以編程。想想代碼編輯器和 IDE 漫長的演變過程。

例如，Visual Studio 支持高效的智能感知，可以單獨查找基類庫中數(shù)千個 API。缺乏良好的源代碼控制是絕大多數(shù)可視化編程工具的另一個主要的缺點。即使這些可視化工具的布局保存為文本的格式，代碼的差異也毫無可讀性可言，因此毫無意義。

我們很難從大塊的 XML 或 JSON 找出每行代碼的修改來源。一些對程序的功能執(zhí)行沒有任何影響的因素，比如圖形元素的位置和大小，也會導(dǎo)致元數(shù)據(jù)的變化，這讓解析差異變得更加困難。

文本編程語言知道將不同的代碼保存到不同的源代碼文件中，因此系統(tǒng)某一部分的變更很容易與另一部分的變更合并。

可視化編程工具通常會將每個圖表保存在一個文件中，這意味著合并也會成問題，當遇到難以解析差異的語義時，難度會更大。

總之，可視化編程工具提供的優(yōu)勢，即簡化程序的創(chuàng)建和理解只是一個海市蜃樓。

只有在非常簡單的編程中才可行，在這種不理想的形勢下，最好的結(jié)果也不過是說：可視化元素是具有混淆副作用的文本代碼的容器。

補充說明

可能在第一段中加上 Scratch 的截圖并用作主要示例是錯誤的做法。我不是一名教育工作者，我不知道 Scratch 是否可以作為一種有效的教學(xué)工具。

許多人提到，Scratch 在編程教學(xué)方面非常有用，特別是對兒童而言。任何可以引導(dǎo)人們進入精彩紛呈的編程世界的東西，我都歡迎。

我并不想通過這篇文章抨擊 Scratch，提到它只是因為它是大多數(shù)人都聽過的最有名的可視化編程系統(tǒng)。

有人在 Reddit 上提到的另一個反面例子是靜態(tài)結(jié)構(gòu)工具，例如 UI 設(shè)計工具、數(shù)據(jù)庫模式設(shè)計工具或類設(shè)計工具。

我同意這些工具非常有用。任何有助于可視化數(shù)據(jù)結(jié)構(gòu)、或程序的大規(guī)模結(jié)構(gòu)的工具都是好東西。

但這些不足以支撐他們的論點。PowerBuilder 等 90 個試圖通過在圖形可視化之上構(gòu)建工具，來開發(fā)出一個完全不用寫代碼的開發(fā)環(huán)境，可是最終都失敗了，這恰恰證明了我的觀點。

你如何看待可視化編程？

針對可視化編程并不是理想的想法，評論區(qū)的不少網(wǎng)友也發(fā)表了不一樣的看法：

評論1：

你混淆了圖形數(shù)據(jù)流語言（帶有隱藏選項框和連接這些框的箭頭）與Scratch。Scratch 是一種文本語言，里面的程序語句和類型是預(yù)定義的形狀，可以消除語法錯誤。

你無法在 Scratch 中犯語法錯誤，因為這些框無法組合在一起。 除了這種語法幫助之外，Scratch 不會隱藏任何內(nèi)容，并且格式也與純文本語言沒有差別。

也就是說，我同意你說的有關(guān)其他教學(xué)語言的大部分內(nèi)容，例如用于 Lego Mindstorms 機器人套件的語言。

該語言源自 LabView，大多數(shù)初學(xué)者發(fā)現(xiàn)很難超越幾個塊或連接變量之類的東西。我的猜測是，一種能夠通過變量賦值來達到復(fù)雜性障礙的語言并不能很好地擴展:-)。

評論 2：

我認為你的文章的出發(fā)點不正確，因為可視化編程根本不是為程序員準備的。