[phurley67]

We have been a labVIEW team of late and are planning on switching to Java, for two reasons.

The primary reason is a direct response to your last question. Using LabVIEW with version control is difficult. If you have a single developer or only a single development machine, LabVIEW has an integrated versioning system you can enable which will provide the "time machine" aspect of version control without any merging capability, which works effectively.

Once you want to have 5 different people working on different sections of code, we have found it difficult (not impossible) working in LabVIEW. In particular LabVIEW has a tendency to "change" VIs (like files in Java) whenever they are opened, even if you did not make a conscious modification. If developers are not exceedingly careful with their commits GIT (or any other optimized for text versioning system) will shrug and force you to handle the differences yourself. LabVIEW does come with a reasonably useful VI diff/merge utility which can be integrated into git/subversion workflows; however, we have had trouble properly utilizing it, especially compared to the ease with which git can handle merging text files.

Our second issue with LabVIEW has also been mentioned above -- longer/unpredictable deployment times. This is not the compilation process, but rather the way in which code is transferred to the RIO. We have experienced numerous communication failures, resets, incomplete deployments. I suspect this may have something to do with portions of our code running in fast loops, as I do not see the problem on freshly imaged RIOs or teams using very simple configurations. That said deploying new code should not be so significantly impacted by previously deployed code you are trying to replace :-)

Regardless both languages are capable of developing advanced robots and each has their own advantages (e.g. it is very hard to beat LabVIEWs ability to graph/visualize data on the fly during development).

Good Luck