I recently was out visiting developers, some who already used LabVIEW and some who don't, taking input on the
LabVIEW Embedded Development Module. One thing that we know is that LabVIEW allows engineers to program a system even though they don't have a computer science degree or haven't spent years learning C or C++. Unfortunately, we don't have a catchy phrase to describe this class of person. In NI's traditional test market, we could call these folks "test engineers" and that was close enough. Yes, some test engineers knew C and some didn't but it didn't require splitting hairs.
But what about the embedded programming market? You can't currently program an embedded system unless you know C or C++. There's nothing else to use except for a tiny bit of Java and some oldschool ADA or assembly folks. Everyone could probably be defined as a Computer Scientist.
So who is LabVIEW enabling? We have taken to calling the folks that the LabVIEW Embedded Development Module enables "domain experts". After all, they have a lot of valuable knowledge (expertise), even though it isn't in C programming. They have expertise in their domain, be it control theory, biology, mechanics, chemistry, signal processing, whatever. Unfortunately, this term doesn't seem to be understood generally. One person said to me "I saw the word 'domain' and thought you meant the Internet". Hmm, not quite what we had in mind. Other suggestions have been "System Architect" though I'm not sure if that resonates. LabVIEW allows people with big picture knowledge to implement the system but we do expect the person to know some low level details of how the thing actually does work. "Application programmers" in my opinion would be assumed to be computer scientists. "Signal processing" engineers certainly like LabVIEW but that's too narrow.
So, what do you call yourself? If I called you a "domain expert", would the label fit? Would you be offended? Does it sound too grand? Not grand enough?
LabVIEW has programming semantics of "by value". Data on a wire represents the "value" of that thing. You don't have "pointers" to data. You don't typically have "references", except when you are referring to certain objects like files or controls. Being a by-value language rather than a by-reference language makes programming in it less error prone and easier for folks to understand. However, for programmers experienced with languages that make extensive use of by-reference semantics (C & C++ come to mind), it requires a mental shift that some of them aren't happy with.
But I'm not going to start that debate. Instead, I'll talk about the implication of by-value semantics. Let's take the basic case of adding two arrays.
The semantics are easy, input 1 and input 2 are arrays. They get added together and placed into the output indicator. Now, a C programmer would look at this and say "aha! After an item in Input 2 is looked at, it isn't needed any more. I can save memory by taking the result of the addition and storing it back in the memory that was used for Input 2". That is a nice optimization. Unfortunately for the C developer, they would have to write their algorithm differently in order to do that optimization. They would have to store data back into the array by effectively using references.
In LabVIEW, there's no way to get a reference back to Input 2 and store the data back there. We really don't want you to do that anyway. Instead, we'd rather have LabVIEW figure it out and do it for you. And that's exactly what we do using something we call "the inplaceness algorithm". This algorithm figures out what memory locations can be reused to make the application take less memory and run more efficiently. Is this algorithm perfect? No. Does it work? Yes, quite well in fact.
We added a feature to LabVIEW in 7.0 via DevZone and as a true menu item in 7.1 to let you peek under the hood of LabVIEW and watch the inplaceness algorithm work. If you select Tools-->Advanced-->Show Buffer Allocations... you can see this tool in operation
It shows you all of the places that LabVIEW decided that it couldn't reuse memory and had to create another buffer to hold the output data. I will say that this is an advanced tool. It doesn't interpret the location of the buffers, it just shows you where they are. It is not possible to get rid of all buffers, don't try. :-) You can find out a little more about how to use it by clicking the help button or looking at this
help link. The
LabVIEW Memory Management Application Note also gives you insight into what is going on.
So here's a question for the audience. Have you used this tool? Is it helpful? What else would you want to know? (no promises here folks)
