LabVIEW是一種通用的編程語(yǔ)言嗎？

作者自傳
Jeff Kodosky，1976年NI的合作創(chuàng)始人而且從那時(shí)起一直擔(dān)任總經(jīng)理。他在1978年被任命為公司的副董事長(zhǎng)。從1980年到2000任RD部門(mén)的副董事長(zhǎng),而且最近被任命為NI 商業(yè)和技術(shù)伙伴。他之所以聞名是因?yàn)樗麆?chuàng)建了LabVIEW，即公司的圖形化儀器技術(shù)軟件包。在1976年之前，他任職于UT Austin 的ARL。Jeff從Rensselaer理工學(xué)院獲得物理學(xué)士學(xué)位。

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

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

錯(cuò)誤的問(wèn)題
盡管有了調(diào)查結(jié)果，但是我認(rèn)為這是一個(gè)錯(cuò)誤的問(wèn)題而且試圖回答它會(huì)導(dǎo)致錯(cuò)誤的方向。對(duì)我來(lái)說(shuō)，這有點(diǎn)像在問(wèn)：汽車(chē)是不是用來(lái)就座的地方？當(dāng)然你可以在汽車(chē)?yán)锞妥侨绻鞘悄憷盟龅娜?，那么你失去了擁有它可以得到的主要用途。一個(gè)較好的問(wèn)題是：LabVIEW可以被用作通用編程語(yǔ)言嗎？或者更好的是：LabVIEW能夠被用來(lái)創(chuàng)建通用的應(yīng)用程序嗎？

這個(gè)問(wèn)題的新表述在什么被視為通用這個(gè)方面仍然是同樣模糊的，但是它沒(méi)有強(qiáng)調(diào)有時(shí)顯得嚴(yán)謹(jǐn)?shù)臓?zhēng)論，即LabVIEW是不是一種編程語(yǔ)言？一些人并不認(rèn)為它是一種語(yǔ)言，因?yàn)樗皇腔谖谋镜亩宜皇琼樞蚧?。更為奇怪的是，關(guān)于什么被看作是一種編程語(yǔ)言的這個(gè)問(wèn)題上，那些具有計(jì)算機(jī)科學(xué)背景的人持有最為狹隘的觀點(diǎn)。

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

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

如果工具A和工具B可以被用于一定的任務(wù)集，但是工具B具有更多的功能可使它益于完成額外的任務(wù)，哪一種工具是事實(shí)上更為通用的呢？這正是我們關(guān)于LabVIEW問(wèn)題。LabVIEW適于測(cè)量和自動(dòng)化應(yīng)用程序的能力不是來(lái)自于它的基本編程能力被某種方式所限制，而是因?yàn)樗鼈兘?jīng)過(guò)了增強(qiáng)和擴(kuò)展。

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

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

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

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

有時(shí)當(dāng)顯示一個(gè)LabVIEW程序流圖時(shí)，我聽(tīng)到一個(gè)問(wèn)題，“代碼在哪里？”，似乎如果不生成文本代碼那么圖表就是不真實(shí)的。我不得不驚嘆于我們整個(gè)工業(yè)是如何成功地讓世界確信：我們對(duì)傳統(tǒng)編程工具的限制實(shí)際上是一個(gè)優(yōu)點(diǎn)。事實(shí)上，它是一個(gè)嚴(yán)重的缺點(diǎn)，限制了程序編輯器和程序編譯器之間的連接以生成一個(gè)簡(jiǎn)單的ASCII流。人們?cè)谑帜靡粋€(gè)音樂(lè)CD之時(shí)不會(huì)詢問(wèn)文本在哪里。我們不會(huì)擁有或不需要一個(gè)CD的文本版本，因?yàn)槲覀儞碛锌梢灾苯訌囊粋€(gè)的二進(jìn)制存儲(chǔ)格式（適合于工具）來(lái)編輯和播放音樂(lè)的工具。視頻也是這樣。錄像機(jī)記錄和播放視頻時(shí)無(wú)需任何作為中介的文本表示。

因此為什么它不同于編程語(yǔ)言？歷史上，擁有一個(gè)單獨(dú)的編輯器和編譯器是有必要的，而且最早完成的事情是將它們通過(guò)最底層的通用點(diǎn)連接起來(lái)，即ASCII字符。隨著機(jī)器變的越來(lái)越大和越來(lái)越快，集成開(kāi)發(fā)環(huán)境隨之出現(xiàn)，但最底層的通用點(diǎn)卻仍然存在。例如，一個(gè)程序文本縮進(jìn)形式中的有價(jià)值的信息完全被編譯器忽略。許多對(duì)設(shè)計(jì)基于語(yǔ)法編輯器的嘗試最終都失敗了，因?yàn)榘醋址庉嬍侨绱说母畹俟?，以至于不可能達(dá)到按結(jié)構(gòu)編輯的更高層次。編譯器只是接受使用編輯器直接匯編而成的7位ASCII字符流。我們?cè)谥谱鳛槿藗兪褂玫奈谋镜臅r(shí)候使用不同的字體和顏色及類(lèi)型，但是卻沒(méi)有嘗試將這些方面應(yīng)用到我們的編程語(yǔ)言編輯器或編譯器。

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

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

編譯器的速度只是用戶使用LabVIEW感受高效率的眾多原因之一。因?yàn)榫庉嬈鳂?gòu)造了解析樹(shù)，所以它能夠立即給出語(yǔ)法和語(yǔ)義的反饋，從而可以更早、更快的檢測(cè)和改正錯(cuò)誤。

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

甚至圖表中的數(shù)據(jù)類(lèi)型也易于使用。無(wú)需擔(dān)心存儲(chǔ)分配的細(xì)節(jié)即可安排和操作字符串和數(shù)組，這意味著許多錯(cuò)誤如丟失或重寫(xiě)內(nèi)存都不存在。

LabVIEW中所有這些能力的最終結(jié)果就是極大地提高了效率。許多方面的證據(jù)表明相對(duì)于傳統(tǒng)編程工具效率提高了4到10倍。因此，這可能是導(dǎo)致不將LabVIEW視為一種通用的編程語(yǔ)言的最主要的原因。它是一個(gè)更高級(jí)的設(shè)計(jì)工具，從臺(tái)式機(jī)器到嵌入式處理器，再到FPGA。對(duì)整個(gè)LabVIEW社區(qū)來(lái)說(shuō)簡(jiǎn)單地將它稱(chēng)之為一種計(jì)算機(jī)語(yǔ)言也許是不公平的。

結(jié)論
隨著LabVIEW的不斷發(fā)展和進(jìn)化，我們會(huì)繼續(xù)提高效率和性能、擴(kuò)展功能，并擴(kuò)展可能在其上應(yīng)用的目標(biāo)的數(shù)量。然而，我們不會(huì)被語(yǔ)言、編輯器、編譯器、調(diào)試器、設(shè)備驅(qū)動(dòng)器等之間的傳統(tǒng)界線所限制，因?yàn)槲覀兿嘈磐ㄟ^(guò)從基本原理中重新思考這些情形可能在提高性能的同時(shí)減少?gòu)?fù)雜性。而且通過(guò)與LabVIEW用戶團(tuán)體緊密合作，我們將會(huì)把這些可能變成現(xiàn)實(shí)。

所以，結(jié)論就是，LabVIEW是一個(gè)通用的編程語(yǔ)言嗎？不，它的含義遠(yuǎn)遠(yuǎn)超越于此。LabVIEW能夠被用來(lái)創(chuàng)建通用的應(yīng)用程序嗎？絕對(duì)可以。