[Greg McKaskle]

I've inserted comments with >>s.

... just think of all the c++ libraries in existance. Although many wont be applicable (like, say, the directX library), others could be very useful, such as a sockets library for sending datagram packets across the wifi connection to the oi to display sensor info, etc). Also, it is one of the primary languages used by the mentors for their robots.

>> Both C and LV have enormous libraries available, but of course these will be subset to those portable enough to run on VxWorks. It isn't windows, and it isn't linux. Also, FIRST may not allow arbitrary wifi traffic, at least not within a competition.

2)Personally, ... (try programming a windows app in labview).

>> Actually, it isn't hard. The OI shown in Atlanta was written in LV, as was the Mindstorms NXT environment. Some things are easier, some harder.

4)
>> It will be standard LV, but with a simplified palette option. Over the last few decades, LV has grown to include tons of functionality, and this is an attempt to filter it to the needs of very bright high school teams. The full set will still be installed and available when desired. Additionally, some of the toolkits for LV will be included, such as vision. Most importantly, the FRC or WPI libraries will be integrated.

5)
>> A good way, but it may be just as valuable to go through some PC examples for LV. LV is cross-platform and the code written for the PC is the quickest to develop, and can later be targeted to the cRIO, NXT, etc. The biggest limit you will find on the NXT is the limited data types and programming palette. The subset of LV that NXT supports is very basic. Cool, but basic.

6)...running windows xp sitting on your robot which the cRio talks to using its ethernet port.

>> One reason XP and an SBC weren't the primary computer is the boot time, size requirements, etc. Also, the latency of going over TCP or UDP is large compared to internal busses, so this data path would need to be used wisely. I'm also not sure if FIRST will consider the multi-computer approach legal.

... While i dont know if labview can do this, I think that it would be much more difficult than in c++.

>> The TCP and UDP stuff in LV is quite nice. The data parsing isn't as nice as in some rapid prototyping languages, but it works fine once you get used to it.

pros/cons:

>> Your list was a pretty good one in my opinion, but I'll list what I've experienced as the major differences between these languages.

C/C++ are expected to have the flexibility to write a complete OS such as unix. They plug into every nook and cranny of the HW, no matter how icky or low-level. You can cast pointers, for good and evil, and build amazingly efficient data structures and algorithms provided you can debug them. Summary: the ultimate in flexibility, but one line of code can contain so many bugs, it boggles the mind. Thus one of the more expensive and time-consuming languages to use for development.

LabVIEW is a higher level language. It puts more emphasis on the problem domain, and less on the syntax or logistics of your program. Because you don't have pointers and the like, it is simultaneously easier to get the code working, and harder to get the same control or efficiency as C. This is the same tradeoff as most other higher order rapid prototyping languages. Graphical is the first element people notice, but the data flow approach is really the more fundamental difference. It makes parallel code so easy that whole new approaches are now feasible, and a C/C++ developer scared of threads may need to reconsider their approach to fully use LV. LV is also good for unit testing and modular development.

Other distinct differences are the debugging tools. LV has some nice ones. C/C++ has some different nice ones. I use and really enjoy using both languages.