Re: PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA
 

My first programming language was LabVIEW, in the form of the LEGO Mindstorms Robolab programming language. Robolab was (and still is) a straight dose of LabVIEW - I learned how to use the front panel, LabVIEW loop and case structures, and more.

A few years later I learned C on an old machine running DOS. I started programming for FRC in 2005, when it was straight C running on the microprocessor. Printf was about all we had for debugging, and I learned to make good use of it.

Now my current preference is Java, for three simple reasons: The Netbeans IDE is easy to set up and it's cross-platform, high school students taking AP computer science learn Java, and I'm comfortable and competent with the language.

I like LabVIEW, and I've found myself defending it against the angry jabs of frustrated mechanical engineering students at school. I've done some cool things with LabVIEW, and it does make a lot of hard tasks easy.
But I've never gotten really comfortable with LabVIEW. I feel like I spend more of my time hunting for the right block and rearranging things on the block diagram than I do actually programming. Maybe I'm just doing it wrong, but large programs seem difficult to manage and hard to change without making a mess. Comments seem more like labels and less like nodes in a thought process. That is, with Java/C++/Python/etc I can write out what I want to do in plain English and fill in code from there. That process doesn't seem as natural in LabVIEW, perhaps only because I'm not as fluent with it.

Have I just spent too much time with text-based languages and not enough with LabVIEW? Maybe I should stop thinking sequentially, and bask in LabVIEW's dataflow goodness? Or should I give up and become an old grouchy programmer who says LabVIEW isn't a real language?

Re: PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA
 

It took me two FRC seasons with LabVIEW to start creating subVIs. If you put everything all in one big VI, large programs do end up being difficult to manage. That's sort of the equivalent of putting your entire C++ program in the main() function. Instead, split functions out into appropriate chunks and it gets a whole lot simpler.

I rarely rearrange things on the block diagram by hand. The "clean up" tool is sufficient for my purposes. If a VI gets too big for me to find things quickly, that's a strong hint to me that it's just plain too big, period.

I just figured out this year how to do "top-down" programming in LabVIEW. You don't have to create complete functional blocks in order to use them. You can "sketch in" a placeholder with appropriate inputs and outputs, turn it into a subVI, pretend it does what you want while you code around it, and later come back and finish it.

In my own analysis, LabVIEW for FRC does lose out to C++/Java/Python in a couple of ways. First, code in a text-based language can be viewed, edited or sent by email without having to have the compiler available. Second, it still takes an annoyingly long time to build and deploy a program from LabVIEW. Those aren't enough to keep me from strongly preferring the ease of learning and speed of programming with LabVIEW. Now that our team's student programmer has had a season of experience, though, I'm going to dial back my preferences a bit and let him choose the path for next season.

Re: PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA
 

If you really want to learn a language well, then you have to learn another language. I picked up more from my comparative programing course about programming than I have any other single class. LABVIEW is a data-flow language, with implicit parallelism, C++ is a object oriented language (though closer to just being a procedure language as used in FIRST) with explicit parallelism.

Once you understand how you can use these two languages to do the same thing in totally different ways you will have made a serious leap towards being a very good programmer.