LABVIEW 有哪些反人類的編程特性？

01-05

我所知道的是：需要手動連線。執行順序無法預計（需要加入sequential frame）。難以定義的全局變數和局部變數。取變數和寫變數需要生成node。線最後會無限長。你的圖最後會無限大。數組的支持簡直讓人想死。基本不存在什麼高級數據結構。沒有函數。

（汗，第一次用。感情評論和回答不同啊）

一看就是不懂LabVIEW的。挑幾個說吧：

- 執行順序無法預計：完全可以讓其有預計。說無法預計的願意其實是因為LabVIEW本身就是多線程運行的，這是其優點之一，不是缺點！

- 難以定義的全局變數和局部變數：不知所謂。但應該盡量少用全局變數。有一種程序型全局變數（Functional Globe Variable）用來做多線程極好。

- 線最後會無限長。你的圖最後會無限大：顯然是你編程概念太差，不懂編程模塊化的概念。

- 基本不存在什麼高級數據結構：會多層Cluster和Class么？

- 沒有函數：每個VI都是函數啊！！！

其實題主問題在於對LabVIEW理解太少了。。

函數的概念在LabVIEW中就是子VI的概念

可操作的數據結構除了數組還有類似C的指針操作：Data value reference

然後其實變數只是為了方便小程序或者新手來解決問題，缺陷是很明顯，所以除非項目對這個可能的風險不計較或者沒有影響，一般不會選著變數來進行數據操作

LabVIEW的執行順序其實是有規律的，什麼要連線呢？因為執行順序就是和連線相關的，從最開始到最後，每通過一個子VI，這個子VI開始運行的前提的就是所有連線的數據已經到達。所以變相通過連線（一般是錯誤簇）來控制執行順序。

當然項目中會用到很多其他的架構來實現，題主如果願意深入研究的話應該會發現更多有幫助的地方。

答主如果是新手，那麼建議好好努力吧。

答主如果是老手，那麼更加需要努力了-_-||

1.「執行順序無法預計（需要加入sequential frame）」忘記順序，這是一門新的語言，需要新的思維。數據流編程需要通過掌握數據流向掌握執行順序。

2.「難以定義的全局變數和局部變數。」

使用了7年，一直沒有遭遇過這個問題，不清楚答主如何遭遇這個問題。

3.其他無限長，無限大，沒有函數的問題歸根結底是一個問題:子VI和調用的問題，樓主可以再學習一下。

LabVIEW往往被看做給那些幾乎沒有軟體工程和編程經驗的人使用的簡單工具。但實際上它是一種功能豐富的，成熟而健壯的軟體開發環境。這種認知與實際情況的落差我覺得才是LabVIEW「反人類」的地方。為什麼會有人認為沒有經驗的人也能創造出良好的應用程序呢？太反人類了

不能放大

LabVIEW 最反人類的地方是明明是從左到右的的數據流滑鼠滾輪控制的卻是上下

23333333333333333333333

我們實驗室生理數據採集，自從用了 labview配套的硬體，就再也回不去了。

LabVIEW不好的地方很多，但題主的幾個都沒噴到點子上

需要手動連線。//這個是其一，會影響一些效率，為了以後好讀，排整齊是值得的；
執行順序無法預計（需要加入sequential frame）。//LV缺少try catch，error只能通過in out傳遞，順帶解決了順序問題，subVI優秀實踐也是if(error==true)則透傳，else才是正式業務邏輯。
難以定義的全局變數和局部變數。//多傳值或傳引用，全局和局部變數要剋制地使用
取變數和寫變數需要生成node。//用傳ref方式代替，在本vi雖然功能一樣，ref可以傳給其他vi啊
線最後會無限長。你的圖最後會無限大。//做個800x600的模板，萬一需要只做橫向擴充；這個問題跟「Java的main裡面都是代碼，好長好難受」的抱怨一樣，代碼長了都要封裝！
數組的支持簡直讓人想死。基本不存在什麼高級數據結構。//算是一個不痛不癢的，沒有map，官方example用兩個array來代替map，tree我一般用composite模式自己搭，用面向對象設計模式；
沒有函數。//vi可以當函數使用，vi的ref也能傳給其他vi來call，有點函數式編程的意思，不過我覺得用LV的人都意識不到或是不願意這樣用的；
還有很多人說的沒有放大縮小功能；很慶幸過去沒有，一旦有了，維護代碼就哭死去吧，新手就別想意識到封裝了，但是！NXG居然可以了，維護別人代碼的同學們等死吧，哈！哈！哈！

下面開噴：

雞肋的面向對象：

沒有向C++的多繼承或是Java的區分Class和Interface，使用的時候，介面繼承和實現繼承一起想要的話，只能選介面繼承，而通過組合方式來達到實現繼承的效果，嚴重不方便；
LV寫個類就是「累」，文本編程一分鐘都不用就寫好的類結構，LV寫起來累死你，特別是浪費在連線排版上的時間，比起純面向過程時累多了，類封裝和vi封裝浪費的時間根本都不在一個數量級；
都是複製，沒有引用，就實現個單例都難看得要死；拿出來用完還要塞回去才算完；（好吧，這不是針對面向對象）
調試。LV面向對象的調試就是個大坑，console也不給一個，log都沒有官方模塊

2. 自帶模板不規則：

用它自帶模板生成個vi，裡面的框線全都是亂糟糟的，每次安裝完新版本，都要把template收拾一頓才能開工

3. 最最不能忍的是這個——沒法diff！！！

哪位好心的大大，開發個lv在git下的diff工具吧，誰改、改了什麼一目了然那種，方便回退和merge

4. UI的開發直接拖拽這個很方便，但運行過程的自帶縮放特效不能忍，自己去控制又太麻煩，麻煩？自己死磕去

5. LV生態跟微軟走太近，我還懂Java、JavaScript、python，用不上；（其實有web編程的，不過，web誰用LV）

6. Mac版？沒驅動啊，純邏輯誰需要LV啊

7. 交流低效。文本編程貼一段在IM，就可以直接看到或是copy走。用LV，麻煩截圖(看你if要截多少個圖)，發個.vi文件也沒法預覽，老老實實下載下來用慢吞吞的LV打開，沒依賴？自覺省略去；低版本打不開高版本？我就是想看一段邏輯啊，要我新安裝？開玩笑！

8. 非同步。大部分的庫都是同步的，LV任性的多線程可以繞過這個問題，出於對非同步的喜愛特意列出來。

總結來說，用LabVIEW有如下經驗：

單人或少人開發，展示、業務邏輯、框架不分，怎麼快怎麼上；
Event-Queue打天下，解決80%快速開發的項目；面向對象？Actor？如果你對接手你項目的仁兄有深仇大恨的話，一定要上！
LV的強項在於UI搭建極快、豐富的工業組件、隨意多線程、豐富而集中的數學庫、還有NI自己的硬體；

要善於利用LV的這些優勢，避開各種劣勢，在測控環境中，穩定、快速交付、簡單修改，這些才是項目成功的王道，特別是非標項目。

目前在測控領域，還沒有另外一種語言能比LV更能平衡好門檻低、開發快、穩定的核心需求，如果有，請告訴我（C#、C/C++、甚至python都不算）；

1,LABVIEW是數據流驅動執行的，最忌諱用順序結構和局部變數以及全局變數，盡量用移位寄存器代替數組

2，可以考慮用控制項的引用簇來對控制項進行操作

3，選擇好架構，比如隊列簇+狀態機。

深入進去你會發現樂趣無窮，加油！

除了取變數和寫變數需要生成node這一條，其他都是錯的。

先說一句，執行順序無法預計是錯誤的，人家就是這樣一個任性的邏輯語言，運行到pxi上你就理解這種模式多麼可愛了，兩個並列的while循環真的是並列，一點也不比只有一個同樣的循環運行得慢，像fpga一樣。

然後，順著題主說點不足吧，如果在電腦上運行，很多地方需要加延時，否則運行程序時電腦會卡死。程序一旦複雜，就會很難理順很難規劃。

貌似題主的看法被群毆了…ORZ…

我想說的是，每種軟體必有它自身的優勢，不然早淘汰了，LabView主要還是應用在工業控制領域的，其功能之強大、將複雜工程問題簡潔化的優勢是其它軟體無法比擬的～NI的技術支持貌似很喜歡舉的一個例子就是美國space X公司發射火箭使用了LabView，聽起來確實高大上…

它上手比較快（當然學得深用得好還是有難度的），所以對於我這種不專業的菜鳥，用來解決工作上一些簡單的儀錶控制數據採集，真是覺得好好用^_^

隨手扯的測試平台沒必要拿編程語言的標準來衡量。能想到的：

面向對象不太好用。

程序執行過程里添加個控制項比較麻煩（可以用 script，但我一般都是隱藏一堆控制項，需要的時候讓其顯示）。

以前還利益相關呢，不寫了。

不能放大