[Gene F]

I have to agree that Gdeaver hit the nail on the head! Procedural versus data flow are different beasts, both to be tamed and put to good use. A good conceptual middle ground is to learn to exploit the benefits of procedural programming in a multi-tasked/multi-threaded environment. Spend some time learning to use things like semaphores, messaging, state programming.

I've been programming as a professional since the early '80s. I have used many different languages. My first exposure to LabView came in the early '90s. At the time I was working for a controls company and we were investigating LabView as a tool for developing User Interfaces (UIs). One of the tasks I was assigned then was to implement a serial protocol using it. Not the best tool for the job. Like has been stated earlier each choice has its strengths and its weaknesses. Look at the strengths and weaknesses of your programming team and pick the environment that fills in the gaps. There are ways to use both LabView and C++ in a PC environment and I hope they expose that capability for FRC in the near future.

On another note, early on in using LabView for FRC my son and I wrote a simple motor simulator VI in LabView. It was a great learning experience and gave us some tools to work out the bugs in our PID routines. Has anyone else used LabView to build up a virtual library of useful FRC components?