labview的數據流編程思想是什麼意思？

01-01

求舉例說明，還有它和我們平時接觸的文本編程在思想上有什麼區別。

謝邀。

做為一位在NI工作的軟體工程師，我的意見不能覆蓋所有工程師的見解，特別是RT, FPGA等領域。這裡只就通用軟體的編寫做一些比較。

與面向過程的語言相比（如C）。

（1）圖形化的語言強調的的是直觀。在LabVIEW中強調的編程風格是數據是從左至右的，所有的數據走向都是可見的。如：

數據由輸入x,y，流入處理節點+，得出結果x+y。相比而言，C語言可能會是這樣的：

int Add(int x, int y)

{

return x+y;

}

輸入與結果之間的聯繫是需要人將輸入變數名，計算變數名，返回值關聯起來得出最後的結論。

（2）錯誤處理

在面向過程的程序編寫時，人們常常會忽略錯誤返回值。一般人們習慣於使用返回值來標記錯誤。

如:

ERROR_CODE Func(int a, int b);

而在LabVIEW中，一般的函數都會有error in/error out。而LabVIEW的編寫風格要求開發者將錯誤線都連接起來，一般的函數寫起來會是這樣：

這樣，在前面的代碼出錯時，就不再執行這部分代碼。

（3）多線程

這個是LabVIEW中的一大亮點，使用LabVIEW寫多線程的程序特別的方便，只需要將數據流分叉就可以了：

在這裡，加和減的操作很可能是在不同的線程中執行的，因為這兩者之間並沒有數據的依賴性。總而言之，數據流的編寫更為直觀和易於上手。但是對於CS背景的人來說會非常的不習慣，而且在寫大型程序時也會有代碼太過複雜的問題，所以會使用一些融合的方式。如寫dll在LabVIEW中調用等。

作為一個在NI總部實習過兩次，跟NI合作過兩年的人來說兩句吧。

LabVIEW使用的是Dataflow Model，跟Kahn Process Network非常像，在Computability上是圖靈完全的。也就是說，你（理論上）可以用它做任何計算。

LabVIEW使用Node/Subsystem和Edge來描述一個系統，跟一般的編程語言相比，其最大的特點就是直觀：Node之間通過edge連接，數據流和控制流通過token在edge上傳遞（這個model是homogeneous的，也就是說每次運行只會consume一個token並produce一個token，保證了圖內有無向環時的consistency），每個node每次執行的前提條件是所有input edge上有token存在。你可以很直觀地看到每個節點被執行並將數據向下一個節點進行傳遞。這類Dataflow model非常適合對stream application建模，因為這類application通常需要消耗很多的計算資源，並且可以做到高度並行以及深度流水線處理（類比下GPU）。

LabVIEW這種編程方式非常適合沒有學過編程語言（並且沒有必要學習編程語言）的人上手設計系統（如果把一般的編程語言比作LaTeX的話，你可以把LabVIEW類比成所見即所得的MS Word），因為系統的底層部件和驅動全部由NI提供好，設計者可以像搭積木一樣把這些部件一個個搭起來，組成一個個子系統，然後再用這些子系統去創造更大更複雜的系統。由於NI提供了全套的解決方案（從示波器採集的數據到board上的ADC轉換再到Windows底層驅動再到LabVIEW里的模塊），LabVIEW在各種需要進行數據採集及處理的實驗室都有著廣泛的應用。

LabVIEW的缺點也很明顯：使用LabVIEW很難實現複雜的邏輯運算，尤其是from scratch的，因為LabVIEW假設使用者（非程序員）只是簡單地搭搭積木——比如拖一個示波器到圖紙上然後連接到一個FFT上再輸出波形到一個log文件里，而不是假設使用者implement各種複雜的邏輯運算的。相比於一般的編程語言，LabVIEW的表現力極為有限，幾個嵌套的if...else if...else...加幾個嵌套的loop就會讓一個LabVIEW程序（vi文件，就是一張圖，連一般的IR都算不上）的可讀性降到零點。而且LabVIEW由於本身提供了一攬子解決方案，其所有程序都需要用LabVIEW來開發，想要運行的話也需要專門的LabVIEW runtime環境來運行，整套工具不僅效率極為低下，而且bug層出不窮（尤其是LabVIEW的各種Extension），跟Python/Java這樣的編程語言毫無可比性可言。

最後說一下，像LabVIEW一樣的數據流「編程」軟體有很多（Simulink，Synopsys等等），但是它們很難跟傳統的編程相提並論。這些軟體只是給了很多非程序員但又需要在工作中進行一些計算的人們一種工具而已，跟MS Office一樣，即便你可以拿Excel的VBA玩出各種花樣來，你也很難說Excel是一種編程語言，或者說它代表了一種編程思想。

先get，然後run。 get不到然後 wrong。

傳統的 LabVIEW 是以面向過程的，以數據流動為基本思考過程的編程語言。

在大的框架下，以面向過程為主要思路。（但LabVIEW 編程規範推薦過程中的每個步驟提供是否運行正確的輸出，並且在前一個步驟出現錯誤時，本步驟不執行。這也可以看作基於錯誤數據傳遞的數據流）

在分解步驟中，以思考數據變化為思路。例如：數據採集程序的處理步驟都會對數據產生變化，推薦將數據流動作為該步驟的主線。