2.1 Why Does LabVIEW Rock?

   

We're going to be controversial here. LabVIEW is the best general-purpose language on the market today.

It's not sold as that, it's sold as a test and measurement tool for nonprogrammers. Even seasoned professionals hedge their bets by saying that it is the best tool for certain jobs. In our experience, for a large proportion of projects that come to us, LabVIEW is the best language to program in. The arguments against this statement are reasonably weak. One such argument is that you cannot easily control the mouse pointer image in LabVIEW. Big deal, that is hardly a project stopper; we've yet to find a customer who actually cares about some of the Windows niceties and frills. National Instruments (NI) is making LabVIEW more available through real-time initiative, and we say there will come a day when LabVIEW will break out of its specialist market and go mainstream.

Why LabVIEW is so good is a contentious issue. We spent some time researching various studies and came to the conclusion that we should make up our own study. We're obviously keen on LabVIEW, so is this a keenness based on the peculiar loyalty programmers have with a particular language? Our interest is purely in productivity. We've tried many languages and methodologies and none come close to LabVIEW in pure productivity. So what has LabVIEW got that these languages haven't, and what do we mean by productivity? Let us discuss productivity first. The following is a list of important characteristics of a software language. If the language scores highly in all of them it is reasonable to assume that the language is going to be productive.

  • Readability

    How much of the problem domain is visible on a single computer screen? How much do you need to learn before you can understand the source code? How complex are the primitives of the language? (Primitives are the basic building blocks, if the basic structures and data types are too numerous or not clearly defined the language will be difficult to use.) How clear is the structure of the program? Does the language support information hiding?

  • Writability

    How quickly can you transfer your designs into the real world? Can you separate the design of the User Interface from the underlying source code? Are small changes in the program made by correspondingly small changes in the code?

    Can you break the source code into chunks to hide complexity? Are the interfaces to these chunks clearly defined? Can a hierarchy of these chunks be built up, pushing complexity down to lower levels?

  • Editability

    It's much easier and faster to edit something than to create something new. A blank sheet of paper is the worst thing to start with when designing. What does the language offer in the form of templates, and how easy is it to modify existing code?

  • Reusability

    How much do you have to write from scratch? Can you build on the development environment so that your own code can be reused as seamlessly as the language's own built-in functionality?

  • Understandability

    What does the language offer when trying to visualize the problem? Is the customer likely to be involved in the process, and will the customer be able to understand the general process?

So how does LabVIEW shape up, and is the list we used the complete story?

  • Readability

    LabVIEW is hierarchical in structure so there is no reason why the complete top-level Virtual Instrument (VI) shouldn't be visible on a single screen. The basic primitives and structures are quite small in number (the graphical nature helps to navigate, and the context help is invaluable when learning). The debugging tools are great for understanding the operation of the program.

    The basic structures (Sequence, Case, While Loop, and For Loop) ring-fence their code in a way that couldn't be clearer. This allows the structure of your code to be clearly defined. If you've trawled through tons of nonindented Pascal, C, or BASIC trying to find the end of a loop you'll appreciate this feature.

    The data flow paradigm is simple to understand. Someone with a reasonable amount of experience can decipher even the most unpleasant program. One criticism leveled at LabVIEW is that the data flow paradigm constrains it in some way. These constraints help readability. OO languages such as Visual Basic (VB) become too much of a personal interpretation of the problem domain. Their lack of constraint means that there are 1,001 different ways to solve a problem. For these languages the solution to a problem is more a case of looking it up and cutting and pasting something than working it out.

  • Writability

    When talking to LabVIEW developers about why they like LabVIEW, one thing that is quite often mentioned is that programming in LabVIEW is fun. This would seem to indicate that it scores highly in the writability stakes. If it were difficult to convert your ideas to reality using LabVIEW, you would find it to be less fun. If you had people on your back about your performance, you would also view LabVIEW as less than fun. So do we derive this fun from dragging and dropping icons onto a block diagram? We hope not. We think the fun comes from the graphic design aspects of the language. You create a pleasant User Interface and that makes you feel good. You then create the source code that operates the User Interface and that looks nice too. It's all very satisfying .

    The fact that you can design the User Interface separately from your source code is something to sing about. It now has this in common with quite a few languages (VB, Delphi, and National Instruments' C-based environment (CVI) plus there are quite often display builder packages available for languages like SmallTalk and Java). Can functionality be added to the displays of these other languages with the customer sitting behind you? Usually not. This is an enormous advantage; the fact that the customer is involved and not excluded is an excellent start. The capability to produce prototypes rapidly and, therefore, inexpensively to help gather requirements is one of the unique advantages of LabVIEW.

    Are small changes in requirements echoed in small changes in the source code? If you design your code right in LabVIEW we suggest that even large changes could be accommodated. This changes the whole dynamic of programming. If you are not running in fear of change, you can plan later, in less detail, and get away with it.

    The development environment offers productivity help in other ways, for example, LabVIEW will not allow you to run if there are obvious errors in your code. You can define the inputs of any subVIs so that LabVIEW insists you connect it correctly. This saves time during development, removing the compile>>run>>debug>>recompile methods of old. This only helps with syntactical errors and not logical errors, but any help is good.

    LabVIEW is a hierarchical language and this allows complexity to be managed by breaking the program into chunks. The interface and architecture of these chunks, or subVIs, can be clearly viewed in the hierarchy display.

  • Editability

    One of the espoused advantages of OO is that you can add functionality without affecting the existing functionality (in OO this is achieved by using inheritance). Inheritance is a double-edged sword, and the price of inheritance is readability. The program becomes such a personal interpretation of the problem that it can be quite difficult to pick up someone else's work. That's before you even start to think about interface inheritance and multiple inheritance.

    LabVIEW gives reasonable capabilities where templates are concerned , with Control and VI templates available. Code fragments can be reused by the use of Merge VIs. There is also a vast set of example software available with the standard package.

  • Reusability

    One reasonably critical argument of why LabVIEW was so productive stated that it was because of the huge array of reusable code available with the development environment. This is an advantage, but shouldn't all software languages have the same advantage? Visual Basic, for example, must have at least 50 times more reusable code available.

    So why is the reusable code that comes with LabVIEW so usable, and why does it leverage so much advantage? Clarity of interface is one thing to consider. You will be more likely to reuse the available code if it is easy to use. All VIs are defined by their inputs and outputs. These inputs and outputs are easily viewed by popping up on the context help. "Popping up" is LabVIEW jargon for right clicking and selecting from the menu.

    Your own and other people's VIs can be loaded into the development environment and used as seamlessly as the language's built-in functionality.

    There are data types that can be defined that improve the capability to reuse further and these will be discussed later in the book.

  • Understandability

    Programming is problem solving and you solve a problem by visualizing it. Good programmers can visualize the many states and interactions of their program in their heads and end up having an enlarged node on their brain. This enlarged node grows at the expense of the surrounding areas, these being the areas responsible for memory, small talk, and fashion sense.

Another conclusion of the research is that LabVIEW, being graphical, aids in this visualization. Here's an analogy.

When getting directions in your car the person will give you a list of landmarks , turnings, and place names . If this list is more than five items long you will more than likely forget something and end up lost. After a couple of times you will be able to get to your destination without referring to the list of directions. You will be using the visual part of the brain, which has converted the list of words to the actual objects.

In programming if you are thinking in pictures rather than words, you will be bypassing a level of abstraction in your head. Programming is hard enough on your brain without having to translate text to pictures.

But this is not the complete story. The fact that you are doing something graphical makes the whole programming event something that is watchable. This opens up the whole process, allowing interested parties to get involved from the start. This input is invaluable for developing to your customer's need, and the customer's input is invaluable for understanding the problem.

S. Watts writes a final story. I was moaning to an NI representative about faultfinding a program thrown together by a nonprogrammer fresh from the LabVIEW Basics course. This program was truly horrible and was being used to control a piece of hardware that I was not familiar with on a really old PC. I fixed it after about an hour .

The conversation went something like this:

Me : What on earth are you turning out from these LabVIEW courses? I've just had to fix the most horrible program ever.

NI Rep : Oh yeah, what was the problem?

Me : Oh, it was badly written, using a piece of kit I was unfamiliar with on a really old rubbish PC. It took me nearly an hour to fix it.

NI Rep : An hour, so what was the problem?

Me, losing ground fast : Well, it was really ugly and I struggled.

NI Rep : Yeah, but you fixed it, right?

Me : er . . . Yeah.

NI Rep : LabVIEW's great isn't it!

And he was completely right. If it had been any other language, there is absolutely no way I could have fixed it in an hour.

On a footnote, the NI LabVIEW Basics courses are valuable because they run through the capabilities of the language, but they will not teach you how to design software.


   
Top


A Software Engineering Approach to LabVIEW
A Software Engineering Approach to LabVIEW
ISBN: 0130093653
EAN: 2147483647
Year: 2003
Pages: 66

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net