可視化編程真的有那麼糟糕？
【CSDN 編者按】和傳統的編程方式相比，可視化編程相對來說更為簡單，只需要通過簡單的操作，就可以設計出程序界面，不過，諸多開發者認為，可視化編程大大降低了代碼的自由程度和可控性，還不如棄之不用。但整體而言，可視化編程真的有那麼糟糕嗎？
作者 | Anton Livaja
譯者 | 彎月
責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
以下為譯文：
我想告訴你，如果使用恰當，可視化編程和是圖解推理是一個非常強大的工具集。也就是說，只有當可視化編程紮根於數學和計算機科學並建立堅實的基礎，才能發揮良好的作用。為了降低編程的難度，我們已經對我們的代碼進行了抽象，而圖表等可視化的方法只是實現抽象的另一種方式。
通過對低級代碼的抽象，生成更容易推理的東西。摘自Bob Coecke的著作《Picturing Quantum Processes》。
當前可視化編程工具的缺點
在你頭也不回地離開之前，請聽我一言。考慮到大多數現有的工具及其使用方式，人們不喜歡可視化編程，輕易將可視化編程拒之門外都是完全可以理解的。
首先，拖放的工具就是讓我個人感到沮喪的主要原因，而且似乎也是給可視化編程招來罵名的原因。例如，在構建網站的時候，我們用拖放的方式代替 Node.js 技術，那麼就會嚴重阻礙程序員的工作流程。而且，他們習以為常的工具也無法正常使用。
此外，可視化編程的方式還大大降低了編程的自由程度和可控性。這是可視化編程失敗的典型原因。還有很多例子，比如笨拙的拖放界面，自稱可以簡化編程，實際上卻讓編程越來越複雜，並最終失敗。發生這種情況是由於複雜度缺乏正確的結構而無法管理。
比較下優缺點就會發現，可視化編程並不樂觀，它構造的不良抽象雖然消除了一些低級的複雜性，卻讓大多數程序員都付出了不願承擔的慘重代價。在某些情況下，對於沒有編程經驗的人來說，拖放工具可能是一個很好的解決方案，但專業人士的感覺是：「這是什麼鬼？」如果你是其中之一，那麼我勸你不要看到「可視化編程」的標題就轉頭離開。
什麼是圖解推理
圖解推理就是對特定的上下文中不必要的細節進行抽象，以便專註於你真正關心的細節，而且常常可以讓人們很容易形成直覺。這可以提高某個人以特定方式推理事物的能力。視頻的編碼就是一個例子。我們不會觀看一堆代表視頻的0和1——沒人會做那種傻事。
視頻的二進位編碼與視覺表示。摘自Bob Coecke的著作《Picturing Quantum Processes》。
關鍵在於你要意識到「可視化編程」並不一定意味著「拖放」。正確的可視化編程應當基於圖解推理與正確的數學形式，從而形成一個非常強大的程序員可以利用的工具包。當我說「圖解推理」時，我特指的是狀態機、Petri網、字元串圖和範疇論，儘管還有其他定義良好的數學形式可以使用。有關這些概念的介紹超出了本文的範疇，但是我在最後列舉了一些你可以參考的資源。
更多示例
我不打算在這裡解釋背後的數學原理，但我可以通過幾個強有力的例子，來說明如何通過視覺的方法隱藏低級的細節，並揭露一些對觀察者而言通常不完全透明的深入了解。我最喜歡的一個例子是Bob Coecke的著作《Picturing Quantum Processes》，他向讀者展示了在描述量子過程的時候，如果面對滿紙晦澀難懂的字元，我們無法憑直覺理解其中的內容，而且還需要大量的前提知識才能理解；但我們可以通過幾張圖表用「正式的方式」（數學中正確定義的方式）來描述。看看下面的這張圖。
描述量子過程的低級語言與高級語言（視覺）。摘自Bob Coecke的著作《Picturing Quantum Processes》。
這個例子與編程沒有直接的聯繫，所以讓我們再來看一個例子。需要注意的是，下述用JavaScript編寫的斐波那契數列與其後的圖形所表示的內容相同（我們需要理解一些語義圖才能看懂）。
function fibonacci(num){
var a = 1, b = 0, temp;
while (num >= 0){
temp = a;
a = a + b;
b = temp;
num--;
}
return b;
}
用信號流圖表示的斐波那契數列。摘自Pawel Sobocinski的博文《?Graphical Linear Algebra》（https://graphicallinearalgebra.net/2016/09/07/31-fibonacci-and-sustainable-rabbit-farming/）。
下面的示例是用可視化的方法對流程進行建模的實際應用。以ATM為例，因為我是區塊鏈技術的粉絲，所以這裡用比特幣ATM為例。從技術角度來看，這是一台經過精心設計的機器，必須避免非法狀態並完成應有的功能。非法的狀態包括貨幣的雙花問題，向用戶發送錯誤數量的加密貨幣，或者沒有向用戶發送加密貨幣，等等。
至於如何利用你現有的知識構建這類的系統，並提供一種圖解的方式，這個難題就留給你來解決吧。我們以比特幣換普通貨幣為例。下面是一個經過簡化後的版本，但可以很好地演示整個過程。
ATM將普通貨幣轉換為比特幣的過程。
上圖是一個簡單的Petri網。那個走來走去的小黑點代表Petri網當前狀態的「令牌」。如你所見，這不僅僅是一個圖表，它還可以通過「觸發轉換」（小矩形代表轉換）捕獲不同的狀態。有趣的是，由於Petri網具有良好的結構，因此可以將上圖編譯成低級語言，而且還可以像與多個微服務或模塊交互的程序一樣運行。這正是我們的Statebox所能完成的功能。現在，就以當前這個為運行比特幣ATM的軟體體系結構而建立的模型為例，我們來對比一下你設計流程時採用的方法，與利用可視化的方法來建模的好處。
使用可視化方法建模與生俱來的優勢
- 非技術人員可以更輕鬆地通過有意義的方式為流程建模做出貢獻。
- 可以減少流程上的錯誤。
- 人們可以訪問應用於Petri網的數學工具，例如檢測死鎖與防止非法狀態的狀態空間分析。
- 更容易確定所有邊界情況，並指出錯誤，因為圖解推理有助於我們對低級信息進行抽象（例如，如果用英語的平鋪直敘或條件語句表達與上圖等價的內容，那麼恐怕遠不如視覺表現形式容易理解）。
- 可以根據流程的不同狀態構建用戶界面，如此一來便更加易於管理系統的狀態與用戶界面顯示內容一致的複雜性，而且與響應式編程有良好的協同效應。
- 雖然Petri網之類的結構不一定是視覺建模事物的專有特性，但有了Petri這種結構，就很容易管理複雜性，因為這樣的結構內部嵌入了大量信息（例如合法的「下一個」狀態集合）。因此，這些工作都無需留到代碼中解決了，而且通常都可以簡化API和中間件。
考慮不同的「級別」
我們需要記住可視化編程不一定要實現低級邏輯，例如與第三方服務，API的交互等。在Statebox，我們認為有效的使用可視化編程的方法是，在更高層次上對事物進行建模（更高層次在這裡可能有點誤導，因為它可以指代高級系統架構或低級的流程，例如上述ATM的運行流程）。通過Petri網的強大功能，將可視化編程與範疇論結合起來，對其行為施加額外的限制，我們就可以構建一個定義良好的語言來定義流程或協議。我們的工具包（雖然目前正在開發中，但已經在現實世界的幾個用例中得到了使用，很快我們就會公布）的設計旨在利用這些經過分類的Petri網的流程進行可視化建模。此外，它還提供了一個引擎，可以實現在網路或流程中從一個狀態轉換到另一個狀態。這本身就是一個強大的工具，但我們正在創建一個完整的開源生態系統，並圍繞這種編程方法創建工具。
到目前為止Statebox系統的功能包括用於Petri網的字元串圖編輯工具，基於事件源的數據存儲方案，分類數據模式遷移，許可權系統中的公私密鑰，merkle樹等區塊鏈和用於數據完整性的散列，相對簡單的函子映射（集成）到其他系統雲服務，區塊鏈，語言等），強類型（我們Petri網風格中的位置和轉換都有類型），自動API和表單生成，根據系統中不同角色的元數據構建的結構化數據，終止擔保以及通過應用狀態空間分析獲得的其他見解，經過簡化的正式流程驗證以及開箱即用的正式驗證組件。此外，我們正在開發一種基於多項式的類型構造語言，實現在不同語言之間進行簡單的「類型轉換」。
以下資源可以幫助你了解Petri網，範疇論和字元串圖表。
資源
以下資源出自我們的各位顧問，他們都是各自領域的世界知名專家。
- Pawel Sobocinski的博文《graphical linear algebra?》（https://graphicallinearalgebra.net/）：
我建議你從第一部分開始閱讀，可以跳過你熟悉的章節。Pawel的工作非常出色，他能夠讓一個沒有任何視覺代數與類別理論的基礎知識的人理解這兩者，並通過圖表與一段時間內建立的語義複雜性讓人明白兩者在直觀方式上的關係。
- Bob Coecke的著作《Picturing Quantum Processes?》：這是一本關於使用視覺方法來理解量子理論的偉大之作。
原文：https://blog.statebox.org/why-visual-programming-doesnt-suck-2c1ece2a414e
本文為 CSDN 翻譯，如需轉載，請註明來源出處。
TAG:CSDN |