[讨论]

LabVIEW之父的一篇文章（转载）

2014-11-26 14:04:59 3689

0 labview之父的一篇文章作者自传 Jeff Kodosky，1976年NI的合作创始人而且从那时起一直担任总经理。他在1978年被任命为公司的副董事长。从1980年到2000任R&D部门的副董事长,而且最近被任命为NI 商业和技术伙伴。他之所以闻名是因为他创建了LabVIEW，即公司的图形化仪器技术软件包。在1976年之前，他任职于UT Austin 的ARL。Jeff从Rensselaer 理工学院获得物理学士学位。我经常听到，甚至有时关注于对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社区来说简单地将它称之为一种计算机语言也许是不公平的。 4
2014-11-26 14:04:59　　评论淘帖0 举报相关推荐 • LabVIW之父谈LabVIEW的未来 6273 • LabVIEW之父eff Kodosky 1423 • 看LabVIEW之父谈论未来LabVIEW的软件架构 18388 • 转载一篇对于新手来说有用的文章，库下载 3219 • 转载一篇MSP430中断c语言函数模板 3 • LabVIEW基本函数_LabVIEW入门篇 0 • LabVIEW宝典(入门篇/高级篇/应用篇) 0 • 剖析MCU的IAP升级软件设计(设计思路篇)【转载】 23 • 基于LabVIEW的虚拟示波器的设计（转载） 27315 • （一）STM32固件库详解（转载） 1821 3 个讨论