As an employer of embedded developers that work in environments such as Android, embedded Linux, VxWorks and several others, I can say the the experience of C/C++ will help ensure that your students are employable. Java is syntactically not that different. I find the use of the JVM does introduce some subtle timing issues, but they can be dealt with in the less than 3 minutes of a match.
In the TIOBE language survey (
http://www.tiobe.com/index.php/conte...pci/index.html) NXT-G has finally been able to break the top 20 whereas C and Java have been at the top of the list for several years. The Labview environment is very rich and well supported by NI. However, as pointed out in an earlier post, it's a proprietary language targeted at NI products. With the exception of the Lego Mindstorms, you won't find Labview in any other environment except those using NI products.
The NI Labview support helps get kids who don't have any software experience up and running quickly. It's a completely different programming paradigm. As long as you're connecting existing VIs together, Labview is quick and efficient. The output code from Labview is a binary. So, from an execution perspective, it's also fast. As also pointed out earlier, the support from NI and here on CD are great.
The issues that I personally have with Labview are twofold. First, it's a very specialized piece of the embedded industry. The number of jobs available with just a Labview background are much smaller than those with Java or C/C++. The second is the process of creating new VIs. Because we in FIRST are always creating new interfaces for the challenge du jour, if a team has to create a new VI from scratch, they are often faced with a seemingly impossible task. If they keep pushing, maybe someone with more experience will come to their rescue. But, if you have to go off the reservation and create a VI that didn't previously exist, many kids get stuck because they have very little source material from which to draw. Try Googling "create a Labview VI" and you'll find that most of the references that come up are all linked back to the same Labview tutorials from NI. Don't get me wrong, Labview isn't *bad* -- just different. But, C/C++ and Java have a lot more sources to choose from.
In the end, it all comes down to the mentor's and student's past experiences and willingness to learn. C++ has a lot of potential gotchas with the use of pointers. However, pointers are what make C/C++ the language of choice for platform development. Even Android (a Java-centric environment) is adding extensive support for C/C++ in it's native development kit in order to get more speed and better hardware integration for games and other high-performance applications. So, if you want to learn C/C++, you'll be positioning your students with a skill that they can carry forward. Many of my C++ students are actually working as C/C++ programmers while they go to college. So, I know the model works. If you've got the time and inclination to try it, C/C++ can be a real positive addition to your robotics program.
All that being said, I'll be working to learn Labview in the off season so we can dork with the dashboard next season. Hopefully, this old dog can learn new tricks.