LabVIEW is unusual among programming languages in that we did not intend to create a new language but rather to develop a tool for non-programmer scientists and engineers to assist them in automating their test and measurement systems.

Prior experience creating software for controlling instruments led us to the perspective that the software ought to be modeled as a hierarchy of “virtual instruments”. The lowest level virtual instruments were simply reflections of the individual physical instruments they controlled. Higher level virtual instruments combined lower level ones to deliver more complex measurements. A frequency response virtual instrument could be implemented using a voltmeter and a sine-wave generator inside a loop that stepped through a frequency range. This was mostly an abstract concept at the time because it was hard to imagine how an existing language or tool could provide the rich yet intuitive experience of using a real instrument.

Inspired by the first Macintosh computer, we quickly realized the graphical user interface would be a natural way to interact with a virtual instrument, but it also sparked our imaginations about using graphics for creating software at a higher level of abstraction.

The February 1982 issue of IEEE Computer was devoted to data-flow models of computation, and it convinced us that graphical data-flow diagrams needed to be part of the solution. The major difficulty we saw, however, was the need to use cycles in the data-flow diagram to represent loops. Cycles increased complexity and made diagrams hard to understand and even harder to create.

This concern led to a major innovation in creating LabVIEW: merging structured programming concepts with data-flow. We represented control-flow structures as boxes in a data-flow diagram. We knew how to reason about loops, so we could introduce them as first class elements of the graphical representation rather than being constructed from lower-level elements. A box could encapsulate the semantics of the iterative behavior; it could clearly separate the body of the loop (the diagram inside the box) from the code before and after the loop (the diagram outside the box); and, its boundary could hold iteration state information.

Those fundamental concepts of “graphical”, “structured” and “data-flow” enabled us to propose a software product. We staffed up a small skunkworks team to implement it. We called it LabVIEW. It was to be an engineer’s tool for automating measurement systems. At first, we were reluctant to admit that we had created a graphical programming language. When we finally did, we nicknamed it G, for Graphical language, so we could talk about the language as distinct from the integrated development environment (IDE), LabVIEW. In practice, almost everyone refers to both the language and the IDE as LabVIEW.

Without intending to do so, we created a programming language radically different from those that came before, pioneering techniques of graphically creating and viewing code, eliminating manual memory management without adding garbage collection overhead, and anticipating the massively parallel systems of the modern era. LabVIEW continues to evolve and thrive after more than 30 years.