1. We will continue to use C, or C++ if OO is really useful for this (think driver control and complex modular end effector systems)

2. C is the industry standard, and frankly, I think that C will continue, at least with veteran teams, just because things like dealing with packet data and interfacing new systems are easier to handle with a text-based language. All experimentation, and complex robot code will probably be done in C. Debugging, though, is where Labview will begin to dominate, since building GUIs is so much easier, and teams can make really nice dashboards.

3. Rookie teams will probably use Labview, just because it doesn't look as intimidating as a C environment with all the functions and brackets, and everything. Things like functions, arguments, parameters, and variable types are all nicely obscured.

4. Was a new version of LabVIEW created specifically for this competition?
A: NI is creating a custom build of LabVIEW made specifically to meet the needs of the FRC
competition. The graphical programming environment, though, is the same one used by hundreds
of thousands of students and engineers worldwide.

That's from the FAQs on the WPI FRC Resources site.

5. YES, NXT would be a great way to prep for LabView (it familiarizes you with wires and stuff like that.) Data flow programming is a slightly different paradigm, and NXT would be good practice.

6. GUIs are very easy with Labview. I've tried Python, C, Java, and VB, and for GUIs related to I/O processing, nothing is easier than LabView. On the other hand, we did have problems with VIs crashing, i.e., CMU2Cam, but hopefully this has been fixed. It just works, and there is amazing documentation if you need it. On the other hand, it will be harder to do a lot of the low-level stuff hard-core embedded systems programmers love to do. Interfacing a custom router, or a PS3 would be a lot harder to code. The capabilities of the C libraries will be easier to modify, and existing C code can be easily ported over, so a lot more code exists. And innovative systems, like the Autoflex 2.0 might take more effort to code.

Personally, I'm planning on having the new programmers on our team write the debuggers and dashboards with LabView, so they learn programming concepts at least, and don't get overwhelmed by the power and complexity of C. But slowly, we will move them from debuggers and dashboards to real robot code, which we will continue to write in C.