LabVIEW是一种通用的编程语言吗？(Jeff K)
时间：12-13
整理：3721RD
点击：
☆─────────────────────────────────────☆
veri (歪理) 于 (Mon Aug 15 10:45:49 2005) 提到:
http://www.ateworks.com/Article/ShowArticle.asp?ArticleID=118
LabVIEW是一种通用的编程语言吗？
作者：Jeff Kodosky 文章来源：LabVIEW之父 点击数：67 更新时间：2005-7-8
我经常听到，甚至有时关注于对LabVIEW的争论，即LabVIEW是一种通用的语言还是一种用于测量和自动化的特定应用程序的开发环境。一方面，有经验的程序员指出了LabVIEW缺乏的流行编程语言所具有的特性，但是另一方面，一些用户详细阐述了他们使用LabVIEW所建立的通用应用程序，而完全没有使用任何数据采集或分析。
对LabVIEW用户的调查可能与最近一个非正式的对一个团队中的开发者的调查一致，这个团队中的绝大多数人都认为LabVIEW已具有足够的功能来被归为通用语言类，而且事实上，正是以这种方式在使用它。LabVIEW被提到次数最多的不足是常用的递归和递归式数据类型，以及面向对象的结构，但是这些都不是建立通用应用程序的严重障碍。
错误的问题
尽管有了调查结果，但是我认为这是一个错误的问题而且试图回答它会导致错误的方向。对我来说，这有点像在问：汽车是不是用来就座的地方？当然你可以在汽车里就座，但是如果那是你利用它所做的全部，那么你失去了拥有它可以得到的主要用途。一个较好的问题是：LabVIEW可以被用作通用编程语言吗？或者更好的是：LabVIEW能够被用来创建通用的应用程序吗？
这个问题的新表述在什么被视为通用这个方面仍然是同样模糊的，但是它没有强调有时显得严谨的争论，即LabVIEW是不是一种编程语言？一些人并不认为它是一种语言，因为它不是基于文本的而且它不是顺序化的。更为奇怪的是，关于什么被看作是一种编程语言的这个问题上，那些具有计算机科学背景的人持有最为狭隘的观点。
但是，经过改正后的问题最为重要的一个方面是它将包容性转换到了正确的方向。换一种方式来表达，即最初的问题间接地暗示了通用编程语言在某种程度上是一个更大的问题或者是测量和自动化编程的一个父集，然而，实际上子集却在其他的方向。
通常，测量和自动化的程序必须处理所有与通用程序一样的问题，如数据结构和算法、文件I/O、网络I/O、用户I/O和数据库存取、打印等等这些常见的问题。但是测量和自动化程序也必须处理比通用程序更多的问题，例如物理I/O、实时性约束和硬件配置。它们也可以具有一些最为苛刻的用户界面要求。测量和自动化程序处理了一个通用程序所处理问题的父集。
如果工具A和工具B可以被用于一定的任务集，但是工具B具有更多的功能可使它益于完成额外的任务，哪一种工具是事实上更为通用的呢？这正是我们关于LabVIEW问题。LabVIEW适于测量和自动化应用程序的能力不是来自于它的基本编程能力被某种方式所限制，而是因为它们经过了增强和扩展。
这就是为什么有必要提出“LabVIEW能够被用来创建通用的应用程序吗？”这个问题而不是“LabVIEW是一种通用编程语言吗？”。我们不希望通过把LabVIEW仅视为一种编程语言而限制了它的范围或它将来的发展。
LabVIEW不仅仅是一种编程语言。它是一种高度交互式的开发环境用来快速设计原型和应用程序的渐进式开发，从测量和自动化到实时嵌入式系统，再到通用场合。而且现在，LabVIEW具有了对FPGA编程下载的能力，所以LabVIEW也是一个硬件设计工具。
数据流
LabVIEW的核心是结构化的数据流图。数据流已存在了很长一段时间而且已被深入地理解。事实上，它是一个比流行的基于文本语言的控制流更为丰富的计算模型，因为它的本质是并行的，而C/C++和BASIC则不是——它们必须依赖于对操作系统的库函数调用来实现并行机制。因此，编译器不能确保代码的共享部分被适当地保护，这使得它难以建立并行程序。这些问题在LabVIEW中则不存在。甚至一个初学者都可以设计一个高度并行的应用程序，而且无需额外的努力或知识就可以自动地将它扩展至多个紧密连接的处理器。
数据流一直被倡导为一个用于商业应用程序的设计工具。它被改进为一种备选的计算机体系结构来避免冯·诺依曼（von Neumann）瓶颈。数据流分析是优化编译器的核心。为什么应用程序不使用数据流？一个数据流的自然表示是一个图形或图表，因此在鼠标和计算机图形产生之前，它几乎是不实际的；一个数据流图的文本描述与对一个街道地图的文本描述类似，既耗时又容易产生错误。但是现在，计算机速度不断加快，存储容量不断增长，计算机屏幕不断加大，直接进行交互式的数据流图编辑是十分简单的。
有时当显示一个LabVIEW程序流图时，我听到一个问题，“代码在哪里？”，似乎如果不生成文本代码那么图表就是不真实的。我不得不惊叹于我们整个工业是如何成功地让世界确信：我们对传统编程工具的限制实际上是一个优点。事实上，它是一个严重的缺点，限制了程序编辑器和程序编译器之间的连接以生成一个简单的ASCII流。人们在手拿一个音乐CD之时不会询问文本在哪里。我们不会拥有或不需要一个CD的文本版本，因为我们拥有可以直接从一个的二进制存储格式（适合于工具）来编辑和播放音乐的工具。视频也是这样。录像机记录和播放视频时无需任何作为中介的文本表示。
因此为什么它不同于编程语言？历史上，拥有一个单独的编辑器和编译器是有必要的，而且最早完成的事情是将它们通过最底层的通用点连接起来，即ASCII字符。随着机器变的越来越大和越来越快，集成开发环境随之出现，但最底层的通用点却仍然存在。例如，一个程序文本缩进形式中的有价值的信息完全被编译器忽略。许多对设计基于语法编辑器的尝试最终都失败了，因为按字符编辑是如此的根深蒂固，以至于不可能达到按结构编辑的更高层次。编译器只是接受使用编辑器直接汇编而成的7位ASCII字符流。我们在制作为人们使用的文本的时候使用不同的字体和颜色及类型，但是却没有尝试将这些方面应用到我们的编程语言编辑器或编译器。
更为有趣的是，一些尝试过图形化和图像式编程模型的研究人员具有相似的有局限性的观点。编辑器生成了编译器所解析的图像。这个2D图像是程序而且它打印在纸上与显示在屏幕上一样容易理解。关于图像是如何构造的知识在编译器开始解析图像之时完全被它忽略。
LabVIEW采取了不用的方式。LabVIEW的数据流图比2D多一点，具有在需要时可弹出的有价值信息，例如接线头，但是不会一直出现而混乱了图表。您可以打印出一个LabVIEW应用程序，但是更容易在LabVIEW中观察和浏览它。编译器并不需要解析图表，因为它已经被解析了。编辑器在图表被交互式构造时就构造了解析树。所有构造图形的用户行为也构造了解析树。传送至编译器或保存在文件中的信息比屏幕上可视的图形更加丰富。因此，从这个角度来说LabVIEW更像VCR模式而不是文本编辑器模式。而且传送到编译器的数据越丰富，编译图表的速度就可能越快，以至于用户几乎可以忽略它正在进行。这就意味着进行改变和试验之间的周期可以非常简短。
编译器的速度只是用户使用LabVIEW感受高效率的众多原因之一。因为编辑器构造了解析树，所以它能够立即给出语法和语义的反馈，从而可以更早、更快的检测和改正错误。
编辑器具有一个丰富的操作集，可以通过直接操作来快速创建详细的用户界面。每个模块或VI都拥有一个用户界面这个事实意味着每一阶段的交互式测试都易于完成，而无需编写任何额外的代码。与传统编程工具相比，在LabVIEW中那些必须在有意义的测试之前完成的应用程序部分更少了，这使得设计过程更加迅速。
甚至图表中的数据类型也易于使用。无需担心存储分配的细节即可安排和操作字符串和数组，这意味着许多错误如丢失或重写内存都不存在。
LabVIEW中所有这些能力的最终结果就是极大地提高了效率。许多方面的证据表明相对于传统编程工具效率提高了4到10倍。因此，这可能是导致不将LabVIEW视为一种通用的编程语言的最主要的原因。它是一个更高级的设计工具，从台式机器到嵌入式处理器，再到FPGA。对整个LabVIEW社区来说简单地将它称之为一种计算机语言也许是不公平的。
结论
随着LabVIEW的不断发展和进化，我们会继续提高效率和性能、扩展功能，并扩展可能在其上应用的目标的数量。然而，我们不会被语言、编辑器、编译器、调试器、设备驱动器等之间的传统界线所限制，因为我们相信通过从基本原理中重新思考这些情形可能在提高性能的同时减少复杂性。而且通过与LabVIEW用户团体紧密合作，我们将会把这些可能变成现实。
所以，结论就是，LabVIEW是一个通用的编程语言吗？不，它的含义远远超越于此。LabVIEW能够被用来创建通用的应用程序吗？绝对可以。
作者自传
Jeff Kodosky，1976年NI的合作创始人而且从那时起一直担任总经理。他在1978年被任命为公司的副董事长。从1980年到2000任R&D部门的副董事长,而且最近被任命为NI 商业和技术伙伴。他之所以闻名是因为他创建了LabVIEW，即公司的图形化仪器技术软件包。在1976年之前，他任职于UT Austin 的ARL。Jeff从Rensselaer理工学院获得物理学士学位。
☆─────────────────────────────────────☆
PretendToBe (就当我是熊猫好了) 于 (Mon Aug 15 10:57:23 2005) 提到:
这篇文章的翻译实在不怎么样
☆─────────────────────────────────────☆
veri (歪理) 于 (Mon Aug 15 11:11:28 2005) 提到:
看个大概就可以了，要看原版的就看看这个吧。
The VIEW, by Jeff Kodosky
Is LabVIEW a general purpose programming language?
I often hear, and sometimes get drawn into, the debate over whether LabVIEW is a general purpose language or an application-specific development environment for measurement and automation. On the one hand, experienced programmers point out features of popular languages which are missing from LabVIEW, but on the other hand, some users point to elaborate general purpose applications they built using LabVIEW but without any data acquisition or analysis at all.
A survey of LabVIEW users would likely match a recent informal poll of developers on the team, where the overwhelming majority were of the opinion that LabVIEW has sufficient functionality to be classified as general purpose, and, in fact, use it that way. The most often cited deficiency is native recursion and recursive data types, followed by object-oriented constructs, but neither was a serious obstacle to the general purpose applications that were built.
The Wrong Question.
Poll results notwithstanding, I think this is the wrong question and trying to answer it leads in the wrong direction. To me, it is a little like asking: is a car a place to sit? Of course you can sit in a car, but if that is all you do with it you are missing the main point of having one. A better question is: can LabVIEW be used for general purpose programming? Or better still: can LabVIEW be used to create general purpose applications?
The new formulation of the question has the same fuzziness about what is considered general purpose, but it downplays the sometimes religious argument of whether or not LabVIEW is a programming language. Some people do not consider it a language because it isn't text-based and it isn1t sequential. Oddly enough, the narrowest views of what is considered a programming language are held by people with a computer science background.
The most important aspect of the revised question, however, is that it gets the inclusiveness turned around the right way. Stated another way, the original question indirectly implies that general purpose programming is in some sense a larger problem or a superset of measurement and automation programming. However, the subsetting actually goes the other way.
In general, measurement and automation programs have to deal with all of the same issues as general purpose programs, the common issues of data structures and algorithms, file I/O, network I/O, user I/O, database access, printing, and on and on. But measurement and automation programs also have to deal with many more issues than general purpose programs, such as physical I/O, real-time constraints and hardware configuration. They can also have some of the most demanding user interface requirements of all. Measurement and automation programs deal with a superset of the concerns dealt with by general purpose programs.
If tool A and tool B can be used for a certain set of tasks, but tool B has more functionality that makes it useful for additional tasks, which tool is really the more general one? This is precisely where we are with LabVIEW. LabVIEW1s suitability for measurement and automation applications comes about not because its fundamental programming abilities are restricted in some way, but because they are enhanced and extended.
This is why it is important to ask the question "can LabVIEW be used to create general purpose applications?" as opposed to the question "is LabVIEW a general purpose programming language?" We do not want to limit the scope or the further evolution of LabVIEW by having it viewed as only a programming language.
LabVIEW is much more than a programming language. It is a highly interactive environment for the rapid prototyping and incremental development of applications, from measurement and automation to real-time embedded to general purpose. And now, with the ability to target FPGAs, LabVIEW is a hardware design tool as well.
Dataflow.
At the heart of LabVIEW is structured dataflow diagramming. Data flow has been around for a long time and is well understood. It is, in fact, a much richer computational model than the control flow of popular text-based languages because it is inherently parallel. C/C++ and BASIC are not. They have to rely on library calls to operating system functions to achieve parallelism. As a result, the compiler can not help ensure shared sections of code are properly protected, making it difficult to build parallel programs. These problems do not exist in LabVIEW. Even a novice can design a highly parallel application. And no extra effort or knowledge is needed to get it to automatically spread over multiple tightly-connected processors.
Data flow has long been advocated as a design tool for business applications. It is being advanced as an alternative computer architecture to avoid the von Neumann bottleneck. Data flow analysis is at the heart of optimizing compilers. Why not program applications using data flow? The natural representation of a data flow is a graph or diagram, so until the mouse and bitmapped graphics came along, it was simply impractical; text entry of a data flow diagram would be analogous to writing a text description of a street map, time consuming and error prone. But now, with fast, large memory machines, and ubiquitous big screens, direct interactive editing of a data flow diagram is simple.
Sometimes when showing a LabVIEW diagram, I hear the question, "where is the code?", as if the diagram isn't real unless it generates text. I can't help but marvel at how successful we have been collectively, as an industry, in convincing the world that a limitation in our traditional programming tools is actually an advantage. In reality, it is a severe disadvantage to limit the connection between program editor and program compiler to a simple ASCII stream. People don't ask where the text is when handed a music CD. We don't have or need a text version of the CD contents because we have tools that edit and play music directly from a binary storage format convenient for the tools. Same for video. VCRs record and play video without any intermediate text representation.
So why is it different for programming languages? Historically, it was necessary to have a separate editor and compiler, and the easiest thing to do was have them connect with the lowest common denominator, ASCII characters. As machines got larger and faster, integrated development environments appeared, but still the least common denominator connection persists. The wealth of information in the indented layout of a program's text, for instance, is completely ignored by the compiler. There were many attempts to design syntax-directed editors but all ultimately failed because character-by-character editing is so ingrained, it is impossible to get to a higher level of editing structure-by-structure. The compiler just accepts a stream of 7-bit ASCII characters directly assembled using the editor. We use different fonts and colors and type styles when making documents for human consumption, but there is no attempt to exploit these dimensions in our programming language editors or compilers.
Interestingly enough, some researchers experimenting with graphical and pictorial programming models have a similarly limited view. The editor produces a picture that the compiler parses. The 2D image is the program and it can just as easily be understood printed on paper as on the screen. The knowledge of how the image was constructed is completely ignored by the compiler as it parses the image from scratch.
LabVIEW takes a different approach. LabVIEW's data flow diagram is a little more than 2D, with a wealth of information that can pop up as needed, such as tip strips, but isn1t around all the time to clutter the diagram. It is possible to print out a LabVIEW application, but it is much easier to view it and navigate it within LabVIEW. The compiler does not have to parse the diagram, because it is already parsed. The editor constructs the parse tree as the diagram is interactively constructed. All the user gestures that construct the graphics also construct the parse tree. What gets passed to the compiler or saved in a file is much richer than the graphics visible on the screen. So, LabVIEW is much more like the VCR model than the text editor model in this respect. And the richer data that is passed to the compiler makes it possible to compile the diagram very fast, to the point where the user can simply ignore that it's happening. That means the cycle time between making a change and trying it out can be very short.
The speed of the compiler is just one of many reasons for the high productivity users experience working with LabVIEW. Because the editor constructs the parse tree, it is able to give syntactic and semantic feedback immediately, so mistakes are detected and fixed earlier and quicker.
The editor has a rich set of operations to quickly create elaborate user interfaces by direct manipulation. The fact that every module, or VI, has a user interface means that interactive testing is simple to do at each step, without writing any extra code. The fraction of the application that has to be completed before meaningful testing can take place is much smaller in LabVIEW than in traditional programming tools, making design iteration much faster.
Even the data types on the diagram are easy to use. Strings and arrays can be routed and operated on without worrying about the details of memory allocation, which means a whole host of errors, such as losing or overwriting memory, just do not exist.
The net result of all these capabilities in LabVIEW is greatly increased productivity. Anecdotal evidence from many sources suggests four to ten times the productivity of traditional programming tools. This, therefore, may be the biggest reason for not considering LabVIEW to be a general purpose programming language. It is a much higher leverage design tool which scales from desktop machine to embedded processor to FPGA. Calling it just a language would be a big disservice to the entire LabVIEW community.
The Bottom Line.
As we continue the development and evolution of LabVIEW, we will continue improving productivity and performance, extending functionality, and expanding the number of possible deployment targets. However, we will not be constrained by the traditional boundaries between language, editor, compiler, debugger, device driver, and so on, because we believe there are possibilities for improving performance while simultaneously reducing complexity by rethinking the situation from first principles. And by working closely with the LabVIEW user community, we intend to bring these possibilities to fruition.
So, bottom line, is LabVIEW a general purpose programming language? No, it is much more than that. Can LabVIEW be used to create general purpose applications? Absolutely.
Discuss this article on the Developer Exchange.
Author Biography
Jeff Kodosky co-founded National Instruments in 1976 and has served as a Director since that time. He was appointed Vice President of the company in 1978, served as Vice President, Research & Development from 1980 to 2000, and was recently named NI Business and Technology Fellow. He is well-known as the inventor of LabVIEW, the company's graphical instrumentation software package. Prior to 1976, he was employed at ARL, UT Austin. Jeff received his BS in Physics from Rensselaer Polytechnic Institute.
☆─────────────────────────────────────☆
sataco (凶铃再现~~~) 于 (Fri Aug 19 15:52:00 2005) 提到:
文章挺好，呵呵 正合我意
☆─────────────────────────────────────☆
boyue (暑假不回去了) 于 (Fri Aug 19 18:00:18 2005) 提到:
然后编写另类程序去b4或者被b4？
☆─────────────────────────────────────☆
PretendToBe (就当我是熊猫好了) 于 (Fri Aug 19 18:07:00 2005) 提到:
re
☆─────────────────────────────────────☆
sataco (凶铃再现~~~) 于 (Fri Aug 19 18:13:59 2005) 提到:
不另类的也要做做，呵呵，另类的是有空做做 ：）
veri (歪理) 于 (Mon Aug 15 10:45:49 2005) 提到:
http://www.ateworks.com/Article/ShowArticle.asp?ArticleID=118
LabVIEW是一种通用的编程语言吗？
作者：Jeff Kodosky 文章来源：LabVIEW之父 点击数：67 更新时间：2005-7-8
我经常听到，甚至有时关注于对LabVIEW的争论，即LabVIEW是一种通用的语言还是一种用于测量和自动化的特定应用程序的开发环境。一方面，有经验的程序员指出了LabVIEW缺乏的流行编程语言所具有的特性，但是另一方面，一些用户详细阐述了他们使用LabVIEW所建立的通用应用程序，而完全没有使用任何数据采集或分析。
对LabVIEW用户的调查可能与最近一个非正式的对一个团队中的开发者的调查一致，这个团队中的绝大多数人都认为LabVIEW已具有足够的功能来被归为通用语言类，而且事实上，正是以这种方式在使用它。LabVIEW被提到次数最多的不足是常用的递归和递归式数据类型，以及面向对象的结构，但是这些都不是建立通用应用程序的严重障碍。
错误的问题
尽管有了调查结果，但是我认为这是一个错误的问题而且试图回答它会导致错误的方向。对我来说，这有点像在问：汽车是不是用来就座的地方？当然你可以在汽车里就座，但是如果那是你利用它所做的全部，那么你失去了拥有它可以得到的主要用途。一个较好的问题是：LabVIEW可以被用作通用编程语言吗？或者更好的是：LabVIEW能够被用来创建通用的应用程序吗？
这个问题的新表述在什么被视为通用这个方面仍然是同样模糊的，但是它没有强调有时显得严谨的争论，即LabVIEW是不是一种编程语言？一些人并不认为它是一种语言，因为它不是基于文本的而且它不是顺序化的。更为奇怪的是，关于什么被看作是一种编程语言的这个问题上，那些具有计算机科学背景的人持有最为狭隘的观点。
但是，经过改正后的问题最为重要的一个方面是它将包容性转换到了正确的方向。换一种方式来表达，即最初的问题间接地暗示了通用编程语言在某种程度上是一个更大的问题或者是测量和自动化编程的一个父集，然而，实际上子集却在其他的方向。
通常，测量和自动化的程序必须处理所有与通用程序一样的问题，如数据结构和算法、文件I/O、网络I/O、用户I/O和数据库存取、打印等等这些常见的问题。但是测量和自动化程序也必须处理比通用程序更多的问题，例如物理I/O、实时性约束和硬件配置。它们也可以具有一些最为苛刻的用户界面要求。测量和自动化程序处理了一个通用程序所处理问题的父集。
如果工具A和工具B可以被用于一定的任务集，但是工具B具有更多的功能可使它益于完成额外的任务，哪一种工具是事实上更为通用的呢？这正是我们关于LabVIEW问题。LabVIEW适于测量和自动化应用程序的能力不是来自于它的基本编程能力被某种方式所限制，而是因为它们经过了增强和扩展。
这就是为什么有必要提出“LabVIEW能够被用来创建通用的应用程序吗？”这个问题而不是“LabVIEW是一种通用编程语言吗？”。我们不希望通过把LabVIEW仅视为一种编程语言而限制了它的范围或它将来的发展。
LabVIEW不仅仅是一种编程语言。它是一种高度交互式的开发环境用来快速设计原型和应用程序的渐进式开发，从测量和自动化到实时嵌入式系统，再到通用场合。而且现在，LabVIEW具有了对FPGA编程下载的能力，所以LabVIEW也是一个硬件设计工具。
数据流
LabVIEW的核心是结构化的数据流图。数据流已存在了很长一段时间而且已被深入地理解。事实上，它是一个比流行的基于文本语言的控制流更为丰富的计算模型，因为它的本质是并行的，而C/C++和BASIC则不是——它们必须依赖于对操作系统的库函数调用来实现并行机制。因此，编译器不能确保代码的共享部分被适当地保护，这使得它难以建立并行程序。这些问题在LabVIEW中则不存在。甚至一个初学者都可以设计一个高度并行的应用程序，而且无需额外的努力或知识就可以自动地将它扩展至多个紧密连接的处理器。
数据流一直被倡导为一个用于商业应用程序的设计工具。它被改进为一种备选的计算机体系结构来避免冯·诺依曼（von Neumann）瓶颈。数据流分析是优化编译器的核心。为什么应用程序不使用数据流？一个数据流的自然表示是一个图形或图表，因此在鼠标和计算机图形产生之前，它几乎是不实际的；一个数据流图的文本描述与对一个街道地图的文本描述类似，既耗时又容易产生错误。但是现在，计算机速度不断加快，存储容量不断增长，计算机屏幕不断加大，直接进行交互式的数据流图编辑是十分简单的。
有时当显示一个LabVIEW程序流图时，我听到一个问题，“代码在哪里？”，似乎如果不生成文本代码那么图表就是不真实的。我不得不惊叹于我们整个工业是如何成功地让世界确信：我们对传统编程工具的限制实际上是一个优点。事实上，它是一个严重的缺点，限制了程序编辑器和程序编译器之间的连接以生成一个简单的ASCII流。人们在手拿一个音乐CD之时不会询问文本在哪里。我们不会拥有或不需要一个CD的文本版本，因为我们拥有可以直接从一个的二进制存储格式（适合于工具）来编辑和播放音乐的工具。视频也是这样。录像机记录和播放视频时无需任何作为中介的文本表示。
因此为什么它不同于编程语言？历史上，拥有一个单独的编辑器和编译器是有必要的，而且最早完成的事情是将它们通过最底层的通用点连接起来，即ASCII字符。随着机器变的越来越大和越来越快，集成开发环境随之出现，但最底层的通用点却仍然存在。例如，一个程序文本缩进形式中的有价值的信息完全被编译器忽略。许多对设计基于语法编辑器的尝试最终都失败了，因为按字符编辑是如此的根深蒂固，以至于不可能达到按结构编辑的更高层次。编译器只是接受使用编辑器直接汇编而成的7位ASCII字符流。我们在制作为人们使用的文本的时候使用不同的字体和颜色及类型，但是却没有尝试将这些方面应用到我们的编程语言编辑器或编译器。
更为有趣的是，一些尝试过图形化和图像式编程模型的研究人员具有相似的有局限性的观点。编辑器生成了编译器所解析的图像。这个2D图像是程序而且它打印在纸上与显示在屏幕上一样容易理解。关于图像是如何构造的知识在编译器开始解析图像之时完全被它忽略。
LabVIEW采取了不用的方式。LabVIEW的数据流图比2D多一点，具有在需要时可弹出的有价值信息，例如接线头，但是不会一直出现而混乱了图表。您可以打印出一个LabVIEW应用程序，但是更容易在LabVIEW中观察和浏览它。编译器并不需要解析图表，因为它已经被解析了。编辑器在图表被交互式构造时就构造了解析树。所有构造图形的用户行为也构造了解析树。传送至编译器或保存在文件中的信息比屏幕上可视的图形更加丰富。因此，从这个角度来说LabVIEW更像VCR模式而不是文本编辑器模式。而且传送到编译器的数据越丰富，编译图表的速度就可能越快，以至于用户几乎可以忽略它正在进行。这就意味着进行改变和试验之间的周期可以非常简短。
编译器的速度只是用户使用LabVIEW感受高效率的众多原因之一。因为编辑器构造了解析树，所以它能够立即给出语法和语义的反馈，从而可以更早、更快的检测和改正错误。
编辑器具有一个丰富的操作集，可以通过直接操作来快速创建详细的用户界面。每个模块或VI都拥有一个用户界面这个事实意味着每一阶段的交互式测试都易于完成，而无需编写任何额外的代码。与传统编程工具相比，在LabVIEW中那些必须在有意义的测试之前完成的应用程序部分更少了，这使得设计过程更加迅速。
甚至图表中的数据类型也易于使用。无需担心存储分配的细节即可安排和操作字符串和数组，这意味着许多错误如丢失或重写内存都不存在。
LabVIEW中所有这些能力的最终结果就是极大地提高了效率。许多方面的证据表明相对于传统编程工具效率提高了4到10倍。因此，这可能是导致不将LabVIEW视为一种通用的编程语言的最主要的原因。它是一个更高级的设计工具，从台式机器到嵌入式处理器，再到FPGA。对整个LabVIEW社区来说简单地将它称之为一种计算机语言也许是不公平的。
结论
随着LabVIEW的不断发展和进化，我们会继续提高效率和性能、扩展功能，并扩展可能在其上应用的目标的数量。然而，我们不会被语言、编辑器、编译器、调试器、设备驱动器等之间的传统界线所限制，因为我们相信通过从基本原理中重新思考这些情形可能在提高性能的同时减少复杂性。而且通过与LabVIEW用户团体紧密合作，我们将会把这些可能变成现实。
所以，结论就是，LabVIEW是一个通用的编程语言吗？不，它的含义远远超越于此。LabVIEW能够被用来创建通用的应用程序吗？绝对可以。
作者自传
Jeff Kodosky，1976年NI的合作创始人而且从那时起一直担任总经理。他在1978年被任命为公司的副董事长。从1980年到2000任R&D部门的副董事长,而且最近被任命为NI 商业和技术伙伴。他之所以闻名是因为他创建了LabVIEW，即公司的图形化仪器技术软件包。在1976年之前，他任职于UT Austin 的ARL。Jeff从Rensselaer理工学院获得物理学士学位。
☆─────────────────────────────────────☆
PretendToBe (就当我是熊猫好了) 于 (Mon Aug 15 10:57:23 2005) 提到:
这篇文章的翻译实在不怎么样
☆─────────────────────────────────────☆
veri (歪理) 于 (Mon Aug 15 11:11:28 2005) 提到:
看个大概就可以了，要看原版的就看看这个吧。
The VIEW, by Jeff Kodosky
Is LabVIEW a general purpose programming language?
I often hear, and sometimes get drawn into, the debate over whether LabVIEW is a general purpose language or an application-specific development environment for measurement and automation. On the one hand, experienced programmers point out features of popular languages which are missing from LabVIEW, but on the other hand, some users point to elaborate general purpose applications they built using LabVIEW but without any data acquisition or analysis at all.
A survey of LabVIEW users would likely match a recent informal poll of developers on the team, where the overwhelming majority were of the opinion that LabVIEW has sufficient functionality to be classified as general purpose, and, in fact, use it that way. The most often cited deficiency is native recursion and recursive data types, followed by object-oriented constructs, but neither was a serious obstacle to the general purpose applications that were built.
The Wrong Question.
Poll results notwithstanding, I think this is the wrong question and trying to answer it leads in the wrong direction. To me, it is a little like asking: is a car a place to sit? Of course you can sit in a car, but if that is all you do with it you are missing the main point of having one. A better question is: can LabVIEW be used for general purpose programming? Or better still: can LabVIEW be used to create general purpose applications?
The new formulation of the question has the same fuzziness about what is considered general purpose, but it downplays the sometimes religious argument of whether or not LabVIEW is a programming language. Some people do not consider it a language because it isn't text-based and it isn1t sequential. Oddly enough, the narrowest views of what is considered a programming language are held by people with a computer science background.
The most important aspect of the revised question, however, is that it gets the inclusiveness turned around the right way. Stated another way, the original question indirectly implies that general purpose programming is in some sense a larger problem or a superset of measurement and automation programming. However, the subsetting actually goes the other way.
In general, measurement and automation programs have to deal with all of the same issues as general purpose programs, the common issues of data structures and algorithms, file I/O, network I/O, user I/O, database access, printing, and on and on. But measurement and automation programs also have to deal with many more issues than general purpose programs, such as physical I/O, real-time constraints and hardware configuration. They can also have some of the most demanding user interface requirements of all. Measurement and automation programs deal with a superset of the concerns dealt with by general purpose programs.
If tool A and tool B can be used for a certain set of tasks, but tool B has more functionality that makes it useful for additional tasks, which tool is really the more general one? This is precisely where we are with LabVIEW. LabVIEW1s suitability for measurement and automation applications comes about not because its fundamental programming abilities are restricted in some way, but because they are enhanced and extended.
This is why it is important to ask the question "can LabVIEW be used to create general purpose applications?" as opposed to the question "is LabVIEW a general purpose programming language?" We do not want to limit the scope or the further evolution of LabVIEW by having it viewed as only a programming language.
LabVIEW is much more than a programming language. It is a highly interactive environment for the rapid prototyping and incremental development of applications, from measurement and automation to real-time embedded to general purpose. And now, with the ability to target FPGAs, LabVIEW is a hardware design tool as well.
Dataflow.
At the heart of LabVIEW is structured dataflow diagramming. Data flow has been around for a long time and is well understood. It is, in fact, a much richer computational model than the control flow of popular text-based languages because it is inherently parallel. C/C++ and BASIC are not. They have to rely on library calls to operating system functions to achieve parallelism. As a result, the compiler can not help ensure shared sections of code are properly protected, making it difficult to build parallel programs. These problems do not exist in LabVIEW. Even a novice can design a highly parallel application. And no extra effort or knowledge is needed to get it to automatically spread over multiple tightly-connected processors.
Data flow has long been advocated as a design tool for business applications. It is being advanced as an alternative computer architecture to avoid the von Neumann bottleneck. Data flow analysis is at the heart of optimizing compilers. Why not program applications using data flow? The natural representation of a data flow is a graph or diagram, so until the mouse and bitmapped graphics came along, it was simply impractical; text entry of a data flow diagram would be analogous to writing a text description of a street map, time consuming and error prone. But now, with fast, large memory machines, and ubiquitous big screens, direct interactive editing of a data flow diagram is simple.
Sometimes when showing a LabVIEW diagram, I hear the question, "where is the code?", as if the diagram isn't real unless it generates text. I can't help but marvel at how successful we have been collectively, as an industry, in convincing the world that a limitation in our traditional programming tools is actually an advantage. In reality, it is a severe disadvantage to limit the connection between program editor and program compiler to a simple ASCII stream. People don't ask where the text is when handed a music CD. We don't have or need a text version of the CD contents because we have tools that edit and play music directly from a binary storage format convenient for the tools. Same for video. VCRs record and play video without any intermediate text representation.
So why is it different for programming languages? Historically, it was necessary to have a separate editor and compiler, and the easiest thing to do was have them connect with the lowest common denominator, ASCII characters. As machines got larger and faster, integrated development environments appeared, but still the least common denominator connection persists. The wealth of information in the indented layout of a program's text, for instance, is completely ignored by the compiler. There were many attempts to design syntax-directed editors but all ultimately failed because character-by-character editing is so ingrained, it is impossible to get to a higher level of editing structure-by-structure. The compiler just accepts a stream of 7-bit ASCII characters directly assembled using the editor. We use different fonts and colors and type styles when making documents for human consumption, but there is no attempt to exploit these dimensions in our programming language editors or compilers.
Interestingly enough, some researchers experimenting with graphical and pictorial programming models have a similarly limited view. The editor produces a picture that the compiler parses. The 2D image is the program and it can just as easily be understood printed on paper as on the screen. The knowledge of how the image was constructed is completely ignored by the compiler as it parses the image from scratch.
LabVIEW takes a different approach. LabVIEW's data flow diagram is a little more than 2D, with a wealth of information that can pop up as needed, such as tip strips, but isn1t around all the time to clutter the diagram. It is possible to print out a LabVIEW application, but it is much easier to view it and navigate it within LabVIEW. The compiler does not have to parse the diagram, because it is already parsed. The editor constructs the parse tree as the diagram is interactively constructed. All the user gestures that construct the graphics also construct the parse tree. What gets passed to the compiler or saved in a file is much richer than the graphics visible on the screen. So, LabVIEW is much more like the VCR model than the text editor model in this respect. And the richer data that is passed to the compiler makes it possible to compile the diagram very fast, to the point where the user can simply ignore that it's happening. That means the cycle time between making a change and trying it out can be very short.
The speed of the compiler is just one of many reasons for the high productivity users experience working with LabVIEW. Because the editor constructs the parse tree, it is able to give syntactic and semantic feedback immediately, so mistakes are detected and fixed earlier and quicker.
The editor has a rich set of operations to quickly create elaborate user interfaces by direct manipulation. The fact that every module, or VI, has a user interface means that interactive testing is simple to do at each step, without writing any extra code. The fraction of the application that has to be completed before meaningful testing can take place is much smaller in LabVIEW than in traditional programming tools, making design iteration much faster.
Even the data types on the diagram are easy to use. Strings and arrays can be routed and operated on without worrying about the details of memory allocation, which means a whole host of errors, such as losing or overwriting memory, just do not exist.
The net result of all these capabilities in LabVIEW is greatly increased productivity. Anecdotal evidence from many sources suggests four to ten times the productivity of traditional programming tools. This, therefore, may be the biggest reason for not considering LabVIEW to be a general purpose programming language. It is a much higher leverage design tool which scales from desktop machine to embedded processor to FPGA. Calling it just a language would be a big disservice to the entire LabVIEW community.
The Bottom Line.
As we continue the development and evolution of LabVIEW, we will continue improving productivity and performance, extending functionality, and expanding the number of possible deployment targets. However, we will not be constrained by the traditional boundaries between language, editor, compiler, debugger, device driver, and so on, because we believe there are possibilities for improving performance while simultaneously reducing complexity by rethinking the situation from first principles. And by working closely with the LabVIEW user community, we intend to bring these possibilities to fruition.
So, bottom line, is LabVIEW a general purpose programming language? No, it is much more than that. Can LabVIEW be used to create general purpose applications? Absolutely.
Discuss this article on the Developer Exchange.
Author Biography
Jeff Kodosky co-founded National Instruments in 1976 and has served as a Director since that time. He was appointed Vice President of the company in 1978, served as Vice President, Research & Development from 1980 to 2000, and was recently named NI Business and Technology Fellow. He is well-known as the inventor of LabVIEW, the company's graphical instrumentation software package. Prior to 1976, he was employed at ARL, UT Austin. Jeff received his BS in Physics from Rensselaer Polytechnic Institute.
☆─────────────────────────────────────☆
sataco (凶铃再现~~~) 于 (Fri Aug 19 15:52:00 2005) 提到:
文章挺好，呵呵 正合我意
☆─────────────────────────────────────☆
boyue (暑假不回去了) 于 (Fri Aug 19 18:00:18 2005) 提到:
然后编写另类程序去b4或者被b4？
☆─────────────────────────────────────☆
PretendToBe (就当我是熊猫好了) 于 (Fri Aug 19 18:07:00 2005) 提到:
re
☆─────────────────────────────────────☆
sataco (凶铃再现~~~) 于 (Fri Aug 19 18:13:59 2005) 提到:
不另类的也要做做，呵呵，另类的是有空做做 ：）