關于LabVIEW的一些爭論

我經(jīng)常聽到，甚至有時關注于對LabVIEW的爭論，即LabVIEW是一種通用的語言還是一種用于測量和自動化的特定應用程序的開發(fā)環(huán)境。一方面，有經(jīng)驗的程序員指出了LabVIEW缺乏的流行編程語言所具有的特性，但是另一方面，一些用戶詳細闡述了他們使用LabVIEW所建立的通用應用程序， 而完全沒有使用任何數(shù)據(jù)采集或分析。

對LabVIEW用戶的調(diào)查可能與最近一個非正式的對一個團隊中的開發(fā)者的調(diào)查一致，這個團隊中的絕大多數(shù)人都認為LabVIEW已具有足夠的功能來被歸為通用語言類，而且事實上，正是以這種方式在使用它。LabVIEW被提到次數(shù)最多的不足是常用的遞歸和遞歸式數(shù)據(jù)類型，以及面向?qū)ο蟮慕Y 構，但是這些都不是建立通用應用程序的嚴重障礙。

錯誤的問題盡管有了調(diào)查結果，但是我認為這是一個錯誤的問題而且試圖回答它會導致錯誤的方向。對我來 說，這有點像在問：汽車是不是用來就座的地方？當然你可以在汽車里就座，但是如果那是你利 用它所做的全部，那么你失去了擁有它可以得到的主要用途。一個較好的問題是：LabVIEW可以被用作通用編程語言嗎？或者更好的是:LabVIEW能夠被用來創(chuàng)建通用的應用程序嗎？

這個問題的新表述在什么被視為通用這個方面仍然是同樣模糊的，但是它沒有強調(diào)有時顯得嚴謹?shù)臓幷摚碙abVIEW是不是一種編程語言？一些人并不認為它是一種語言，因為它不是基于文本的而且它不是順序化的。更為奇怪的是，關于什么被看作是一種編程語言的這個問題上，那些具有 計算機科學背景的人持有最為狹隘的觀點。

但是，經(jīng)過改正后的問題最為重要的一個方面是它將包容性轉換到了正確的方向。換一種方式來表達，即最初的問題間接地暗示了通用編程語言在某種程度上是一個更大的問題或者是測量和自動化編程的一個父集，然而，實際上子集卻在其他的方向。

通常，測量和自動化的程序必須處理所有與通用程序一樣的問題，如數(shù)據(jù)結構和算法、文件I/O、網(wǎng)絡I/O、用戶I/O和數(shù)據(jù)庫存取、打印等等這些常見的問題。但是測量和自動化程序也必須處理比通用程序更多的問題，例如物理I/O、實時性約束和硬件配置。它們也可以具有一些最為苛刻的用戶界面要求。測量和自動化程序處理了一個通用程序所處理問題的父集。

如果工具A和工具B可以被用于一定的任務集，但是工具B具有更多的功能可使它益于完成額外的任務，哪一種工具是事實上更為通用的呢？這正是我們關于LabVIEW問題。LabVIEW適于測量和自動化應用程序的能力不是來自于它的基本編程能力被某種方式所限制，而是因為它們經(jīng)過了增強和擴展。

這就是為什么有必要提出“LabVIEW能夠被用來創(chuàng)建通用的應用程序嗎？”這個問題而不是“LabVIEW是一種通用編程語言嗎？”。我們不希望通過把LabVIEW僅視為一種編程語言而限制了 它的范圍或它將來的發(fā)展。

LabVIEW不僅僅是一種編程語言。它是一種高度交互式的開發(fā)環(huán)境用來快速設計原型和應用程序的 漸進式開發(fā)，從測量和自動化到實時嵌入式系統(tǒng)，再到通用場合。而且現(xiàn)在，LabVIEW具有了對 FPGA編程下載的能力，所以LabVIEW也是一個硬件設計工具。

數(shù)據(jù)流
LabVIEW的核心是結構化的數(shù)據(jù)流圖。數(shù)據(jù)流已存在了很長一段時間而且已被深入地理解。事實上，它是一個比流行的基于文本語言的控制流更為豐富的計算模型，因為它的本質(zhì)是并行的，而 C/C++和BASIC則不是——它們必須依賴于對操作系統(tǒng)的庫函數(shù)調(diào)用來實現(xiàn)并行機制。因此，編譯器不能確保代碼的共享部分被適當?shù)乇Ｗo，這使得它難以建立并行程序。這些問題在LabVIEW中則不存在。甚至一個初學者都可以設計一個高度并行的應用程序，而且無需額外的努力或知識就可 以自動地將它擴展至多個緊密連接的處理器。

數(shù)據(jù)流一直被倡導為一個用于商業(yè)應用程序的設計工具。它被改進為一種備選的計算機體系結構來避免馮·諾依曼（von Neumann）瓶頸。數(shù)據(jù)流分析是優(yōu)化編譯器的核心。為什么應用程序不使用數(shù)據(jù)流？一個數(shù)據(jù)流的自然表示是一個圖形或圖表，因此在鼠標和計算機圖形產(chǎn)生之前，它幾乎是不實際的；一個數(shù)據(jù)流圖的文本描述與對一個街道地圖的文本描述類似，既耗時又容易產(chǎn)生錯誤。但是現(xiàn)在，計算機速度不斷加快，存儲容量不斷增長，計算機屏幕不斷加大，直接進行交 互式的數(shù)據(jù)流圖編輯是十分簡單的。

有時當顯示一個LabVIEW程序流圖時，我聽到一個問題，“代碼在哪里？”，似乎如果不生成文本代碼那么圖表就是不真實的。我不得不驚嘆于我們整個工業(yè)是如何成功地讓世界確信：我們對傳統(tǒng)編程工具的限制實際上是一個優(yōu)點。事實上，它是一個嚴重的缺點，限制了程序編輯器和程序編譯器之間的連接以生成一個簡單的ASCII流。人們在手拿一個音樂CD之時不會詢問文本在哪里。
我們不會擁有或不需要一個CD的文本版本，因為我們擁有可以直接從一個的二進制存儲格式（適合于工具）來編輯和播放音樂的工具。視頻也是這樣。錄像機記錄和播放視頻時無需任何作為中介的文本表示。

因此為什么它不同于編程語言？歷史上，擁有一個單獨的編輯器和編譯器是有必要的，而且最早完成的事情是將它們通過最底層的通用點連接起來，即ASCII字符。隨著機器變的越來越大和越來越快，集成開發(fā)環(huán)境隨之出現(xiàn)，但最底層的通用點卻仍然存在。例如，一個程序文本縮進形式中的有價值的信息完全被編譯器忽略。許多對設計基于語法編輯器的嘗試最終都失敗了，因為按字符編輯是如此的根深蒂固，以至于不可能達到按結構編輯的更高層次。編譯器只是接受使用編輯器直接匯編而成的7位ASCII字符流。我們在制作為人們使用的文本的時候使用不同的字體和顏色及類型，但是卻沒有嘗試將這些方面應用到我們的編程語言編輯器或編譯器。

更為有趣的是，一些嘗試過圖形化和圖像式編程模型的研究人員具有相似的有局限性的觀點。編輯器生成了編譯器所解析的圖像。這個2D圖像是程序而且它打印在紙上與顯示在屏幕上一樣容易理解。關于圖像是如何構造的知識在編譯器開始解析圖像之時完全被它忽略。

LabVIEW采取了不用的方式。LabVIEW的數(shù)據(jù)流圖比2D多一點，具有在需要時可彈出的有價值信息，例如接線頭，但是不會一直出現(xiàn)而混亂了圖表。您可以打印出一個LabVIEW應用程序，但是更容易在LabVIEW中觀察和瀏覽它。編譯器并不需要解析圖表，因為它已經(jīng)被解析了。編輯器在圖表被交互式構造時就構造了解析樹。所有構造圖形的用戶行為也構造了解析樹。傳送至編譯器或保存在文件中的信息比屏幕上可視的圖形更加豐富。因此，從這個角度來說LabVIEW更像VCR模式而不是文本編輯器模式。而且傳送到編譯器的數(shù)據(jù)越豐富，編譯圖表的速度就可能越快，以至于用戶幾乎可以忽略它正在進行。這就意味著進行改變和試驗之間的周期可以非常簡短。

編譯器的速度只是用戶使用LabVIEW感受高效率的眾多原因之一。因為編輯器構造了解析樹，所以它能夠立即給出語法和語義的反饋，從而可以更早、更快的檢測和改正錯誤。

編輯器具有一個豐富的操作集，可以通過直接操作來快速創(chuàng)建詳細的用戶界面。每個模塊或VI都擁有一個用戶界面這個事實意味著每一階段的交互式測試都易于完成，而無需編寫任何額外的代碼。與傳統(tǒng)編程工具相比，在LabVIEW中那些必須在有意義的測試之前完成的應用程序部分更少了，這使得設計過程更加迅速。

甚至圖表中的數(shù)據(jù)類型也易于使用。無需擔心存儲分配的細節(jié)即可安排和操作字符串和數(shù)組，這意味著許多錯誤如丟失或重寫內(nèi)存都不存在。LabVIEW中所有這些能力的最終結果就是極大地提高了效率。許多方面的證據(jù)表明相對于傳統(tǒng)編程工具效率提高了4到10倍。因此，這可能是導致不將LabVIEW視為一種通用的編程語言的最主要的原因。它是一個更高級的設計工具，從臺式機器到嵌入式處理器，再到FPGA。對整個LabVIEW社區(qū) 來說簡單地將它稱之為一種計算機語言也許是不公平的。

概要
隨著LabVIEW的不斷發(fā)展和進化，我們會繼續(xù)提高效率和性能、擴展功能，并擴展可能在其上應用的目標的數(shù)量。然而，我們不會被語言、編輯器、編譯器、調(diào)試器、設備驅(qū)動器等之間的傳統(tǒng)界線所限制，因為我們相信通過從基本原理中重新思考這些情形可能在提高性能的同時減少復雜性。而且通過與LabVIEW用戶團體緊密合作，我們將會把這些可能變成現(xiàn)實。

所以，結論就是，LabVIEW是一個通用的編程語言嗎？不，它的含義遠遠超越于此。LabVIEW能夠被用來創(chuàng)建通用的應用程序嗎？絕對可以。