I'd much prefer to stick with text based programming for the same reasons already mentioned by others. I can see some benefits to the Labview environment and done right it can work.
However, getting it "done right" can be tricky. My FIRST Labview experiences have not made a good impression. This applies to both trying to get the Camera code working a couple of years ago and trying to do a data acquisition project last year. I'll admit to not doing much of the tutorials, but a lot of my concerns really aren't covered in the ones I did try.
- Installation instructions have been poor or missing, even with correct instructions it takes a long time to install. We usually have four classroom computers plus at least two mentor or loaner laptops.
- Sample applications have been buggy and cumbersome. (Think version 1 of CMUCam application)
- The environment likes to start up device drivers for devices when you start the system. I still get occassional error messages from some LV process while shutting down my laptop.
- LabView also likes to go out to the network when you start it. When I'm programming for FIRST, I hardly ever have a network connection. I think I eventually figured out how to turn this off.
- LabView (or at least the applications I've tried) seem to require a lot nicer laptop than the hand-me-down school laptops we've used.
I'm sure we can work with it, but as I've said elsewhere, the sooner we know what we're working with the better. This would be a major change, not just a rehashing the current code. Labview based development will call for an entire new set of training resources. The demo at Kettering made it look more promising than I would have thought, but the details are key to making it work.