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

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

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

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

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

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

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

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

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

第一個(gè)誤解認(rèn)為軟件開發(fā)的門檻很高，因?yàn)槲谋揪幊陶Z(yǔ)言混淆了編程的本質(zhì)。Scratch 在教育學(xué)家中的流行就屬于這種誤解。

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

我認(rèn)為這種誤解是因?yàn)橛行┤宋茨苷嬲x懂用標(biāo)準(zhǔn)的文本編程語(yǔ)言編寫的程序，并想象可以將程序轉(zhuǎn)換成盒子和箭頭等圖形元素。

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

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

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

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

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

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

因此才有了第二個(gè)誤解，即抽象和解耦是外圍問題?？梢暬幊碳僭O(shè)大多數(shù)程序都是簡(jiǎn)單的程序序列，有點(diǎn)像流程圖。實(shí)際上，這也是大多數(shù)新手程序員想象的軟件工作原理。

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

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

實(shí)際上，好代碼和差代碼之間的本質(zhì)區(qū)別也在于此。可視化編程工具很少擁有有效的機(jī)制來執(zhí)行這些操作，而開發(fā)人員也必將陷入二十世紀(jì)七十年代 BASIC 的漩渦中。

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

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

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

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

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

可視化編程工具通常會(huì)將每個(gè)圖表保存在一個(gè)文件中，這意味著合并也會(huì)成問題，當(dāng)遇到難以解析差異的語(yǔ)義時(shí)，難度會(huì)更大。

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

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

補(bǔ)充說明

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

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

我并不想通過這篇文章抨擊 Scratch，提到它只是因?yàn)樗谴蠖鄶?shù)人都聽過的最有名的可視化編程系統(tǒng)。

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

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

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

你如何看待可視化編程？

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

評(píng)論1：

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

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

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

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

評(píng)論 2：

我認(rèn)為你的文章的出發(fā)點(diǎn)不正確，因?yàn)榭梢暬幊谈静皇菫槌绦騿T準(zhǔn)備的。