Why to use LV/C++/C?

[Gdeaver]

Our team has lost all the programers to graduation. The returning group wants no part of programming. The are several 9th graders who have experience with the lego platform. If they join the team it will be interesting to see how thier use of NXT-G aids them in the programming of the FRC in lab view.

[Michael Hill]

I may be sounding like one of the "older" mentors on this board (perhaps I am? lol, no), but my first programming language I learned was Fortran 90/95. My second was ANSI C. Now when I first started work, I was fairly proficient in either language (really, both languages are good because knowing them, mostly Fortran, is a lost art). However, most of our programs are programmed in LabVIEW. A fundamental difference between these languages is that Fortran and C are "top-down" programming, whereas LabVIEW is a "data-flow" programming language. I do know one thing, LabVIEW does things MUCH easier and faster than C or Fortran (programming wise). For example, you have absolutely no pointers, no worry of memory allocation or anything. It is much easier to use, but it can be quite difficult making the transition for your brain to think in data-flow vs. top-down.

[Alan Anderson]

Originally Posted by Michael Hill

[With LabVIEW]...you have absolutely no pointers, no worry of memory allocation or anything.

That contradicts much of what I've heard about both the specific FRC tools we are told to expect (e.g. DYNAMICALLY ALLOCATED!) and the general style of LabView programming I learned a couple of years ago (e.g. "open" a resource and pass the resulting pointer along to everything else that uses it, remembering to "close" it when finished).

I look forward with a mix of anticipation and dread to actually having this stuff in front of me to work with. My optimistic expectation is that I'll quickly realize what simple concept is keeping me from completely understanding what I'm reading, and that I'll finally "get it". (My nagging fear is that I'm a programming dinosaur, stuck in a procedural tar pit and doomed to extinction as the dataflow mammals take over.)

[JaneYoung]

Originally Posted by Alan Anderson

(My nagging fear is that I'm a programming dinosaur, stuck in a procedural tar pit and doomed to extinction as the dataflow mammals take over.)

If I may, Alan, you will never be a dinosaur of any type, stuck in a tar pit of any type, and doomed to extinction - because you are sticking with it and will see it through - evolving: curious, asking questions, seeking to understand, comprehend, gain skill sets and how to apply them. I think that is a big part of advancing technology and science in any area.

Your written thoughts created an incredible visual.

[slavik262]

Originally Posted by Michael Hill

For example, you have absolutely no pointers, no worry of memory allocation or anything. It is much easier to use, but it can be quite difficult making the transition for your brain to think in data-flow vs. top-down.

Aren't there certain advantages to manually managing memory though? Perhaps I'm also stuck in the procedural tar pit (although at age 16 I would hope I'm not a dinosaur ). I realize that LV may provide faster development, but doesn't C++ provide you with slightly finer control?

[Michael Hill]

Originally Posted by Alan Anderson

That contradicts much of what I've heard about both the specific FRC tools we are told to expect (e.g. DYNAMICALLY ALLOCATED!) and the general style of LabView programming I learned a couple of years ago (e.g. "open" a resource and pass the resulting pointer along to everything else that uses it, remembering to "close" it when finished).

I look forward with a mix of anticipation and dread to actually having this stuff in front of me to work with. My optimistic expectation is that I'll quickly realize what simple concept is keeping me from completely understanding what I'm reading, and that I'll finally "get it". (My nagging fear is that I'm a programming dinosaur, stuck in a procedural tar pit and doomed to extinction as the dataflow mammals take over.)

A lot of things ARE dynamically allocated, most noticeably, arrays. HOWEVER, the biggest difference is that all the dynamic allocation takes place behind the scenes in LabVIEW. The end-user of LabVIEW, i.e. the programmer, i.e. you, never has to worry about using malloc, calloc or anything like that. The only type of thing that I can think that you should have to "close" would be a TCP connection in LabVIEW. You don't have to "close" any other references or anything like that, I least I never have had to in the years I've been programming.

[EricVanWyk]

Originally Posted by Michael Hill

For example, you have absolutely no pointers, no worry of memory allocation or anything.

I am not a software engineer. I am not a LabVIEW expert (barely proficient is stretching it). However, I have (at some point) used more than 10 programming languages, and I have spent enough time with LabVIEW to become frustrated and (later) elated.

I will defer to Greg as to whether or not Michael's assertion is true 100% of the time, forever and ever. I simply don't know.

What I do know is that typical LabVIEW code reminds me of LISP/Scheme in how it handles basic data types. The Liopleurodons among us may benefit of approaching it from that angle - that was the mental leap that made everything "click" for me. Now I think of LabVIEW as Graphical PythonLISP.

To over generalize:

Python -adjective
1) readable and approachable
2) utilitarian / lacking blind devotion to a particular ideology.
3) pretty

I will admit that "pre-click", LabVIEW was frustrating. I kept trying to force imperative programming methods which just weren't appropriate. Now I am rather excited to use it for `09 (especially since I haven't mentored a programming team in FIRST in 2 years).

[Greg McKaskle]

Several things to comment on.

First -- Eric gets it! Yay.
LV is different, not always better or always worse, but because of dataflow, almost always different. It really isn't magic either. Like most industry languages, LV is a mixed bag. A functional core with grafts to allow easier looping and structured programming, more grafts to allow for I/O APIs that use references, and of course the implementation is still missing many of the things that we want it to have.

Second -- Michael is correct.
LV isn't an ideal realtime language, because it does do allocations implicitly. Some languages alloc almost everything in sight, others make it very explicit. LV has many scalar types, or flat types as we refer to them that are statically allocated, but the string and array in particular, are dynamic. There are in fact bounded and fixed variations of them, which will give you better determinism, but they are not used that often. More on LV memory model later in the post.

Third -- I agree with slavik262.
There are certainly situations that benefit from tightly controlling memory allocation as well as other resources. But not only is there a tradeoff in the number of details you need to take on for explicit control, but the power of C's syntax in particular is way into the "user beware" camp. Is x=rand(); *x=5; ever what you meant? The time spent finding an outright nasty memory corruption is quite the tradeoff to make.

Finally -- Alan, you don't sound like a dinosaur, but perhaps a skeptic. I find skepticism to be a critical element in making new things work.

Getting back to the LV memory approach.
I'm not sure this statement will help, but the primary LV types have by-value semantics, even if their implementation is by reference. What this means is that each wire acts as an unnamed temporary storage element. It has one writer and as many readers as you like. So if a wire simply runs between the output of + and the input of =, it is really just binding those together functionally. If the wire forks and delivers the data to multiple inputs, there are no side effects to worry about. The data value is delivered to each. It is impossible for another location on the diagram to modify the wire, no matter what order they are scheduled in, how long it takes to execute, etc. This doesn't seem like a big deal at first, but in a parallel language, it is a cornerstone. This is why variables, global or local ones weren't even in the language for quite some time, and why they need to be used very carefully. Multiple writers allow for race conditions, and the parallel dataflow scheduling makes the race conditions a common occurrence.

If the actual implementation used a by-value approach, LV would be quite a bit slower and bigger than it is. Instead, the compiler analyzes the graph and allows for temporaries to be folded together. It also takes statements that are more parallel than needed by the computer architecture and serializes them into a statically scheduled snippet to help further with memory reuse. Finally, arrays and string wire forks mean the same as a Boolean, but their implementation is different. They are really alloc'ed buffers, and the buffers are commonly shallow copied to improve efficiency, but not at the cost of simplicity to the user.

The exceptions to the by-value semantics are the reference types. Primary ones are I/O such as TCP, files, and UI elements. Copying an entire file around with by-value semantics just wasn't feasible in '83 when they started working on LV, so some APIs expose a reference type which should be closed when completed, similar to most POSIX libs. But trying to improve it slightly, LV does shadow these refs and will close them at program completion or termination, even if you don't.

LV certainly isn't magic, and I'll be happy to explain how things work if you ask the questions.

Greg McKaskle

[EricVanWyk]

Originally Posted by Greg McKaskle

First -- Eric gets it! Yay.

LabVIEW is like the big connectors on the PD: A total pain until you figure out the right way to use them, at which point it is like a godsend. Remember, Slide Not Stab!