[fovea1959]

a viewpoint of a short-timer (4th year) mentor that is a grey beard professional Java developer and mentors a team that just switched from LV to Java, and talks regularly to a team that does C++ and another doing LabView. Many of the issues in this thread have come up in our corner of the world.

I'm also punchy: we just hosted a district competition this weekend that we also competed in. We're *tired*, and if someone asks me to tape another tarp on the floor, I'll die...

• does your school(s) teach any programming? if so, that's a *major* factor in the decision. 4237 (not my team, but I had a son go to school there) has taught C++ in their fine Math and Science Center for quite a while. The switch from LV to C++ between year 1 and 2 was a natural one for them, and has been a good one. We have 3 students in our school doing a remote Java AP class from a college in Florida, and I wish we could have snagged one of them for the team; they would be a *great* complement for our current "I understand I need to get done in 20 ms, and I'm pulling an well-deserved A in my Mechatronics class, but what's this try/catch stuff about?" programmers (not dissing our students!). I didn't have enough time in the off season to teach all of Java *and* teach WPIlib, so I setlled for just teaching a subset of Java (data types, classes, methods, looping, conditionals, methods, etc).
  
• our team did well with LV, until we started getting a lot of programmers. Divvying up a complex robot in LV over several developers working on several dissimilar PCs is no doubt doable, but we never figured it out. Telling a student "create and test a sub-VI on that computer and we'll integrate it into the overall build over here later" was always an exercise in faith for us, and a test of my ability to filter epithets when students were around. I'll concede that knowing how to do it in Java (and C++) is colored by my day job, and I'll bet that NI knows how to do it (and that knowledge is accessible to a determined team that's good with Google), but LV seems to be more tailored to work involving a small group of developers (one programmer can be a small group), or else developers with a highly homogenous build configuration.
  
• for text based: Java vs C++ is probably less of an issue than iterative vs command-based.
  
• support: San Diego must be very far from Michigan. I was the only 1 of 3 CSAs at our district competition that was strong in Java; all 3 of us were comfortable with LV problems. Our other district competition had a team with Java problems, and none of the CSAs had Java experience (*not* dissing the CSAs: they knew where to go for help, and all problems were resolved in a timely manner). A rookie team with an LV problem in Michigan doesn't have enough room in their pit to accomodate all the programmers from other teams that will run over to demonstrate GP once the "help" announcement hits the pit PA. C++ teams in trouble hear cricket noises. Java teams here seem to be in the middle, peer-support-wise.
  
• execution speed. um, how often does it really matter? bad code design or implementation can easily swamp any performance differences between languages. AFAIK (chime in here, folks, I welcome learning more), the heavy lifting for stuff like vision is all pretty much done deep in the bowels of the cRIO by language independent native code; do we really see a difference here? Perhaps I'm not experienced enough, but the only CPU performance problems we generally face are the "get done before the next packet comes from the driver station" and "don't let vision melt down your cRIO CPU" problems...
  
• deployment speed: it depends. I went and helped my old team with a LV problem last week, and got reminded of the "first deployment takes forever, redeployment of a handful of changed VIs is *so* quick" phenomenon. Java deployments, for major or minor changes, all seem to cost a near-constant-time build/copy/reboot (which will change in 2015).
  
• version control. we've done version control with SVN and GIT. the students *love* looking at a diff between Tuesday and Thursday and being able to answer precisely when the build team asks "ok, what did you change again?". doable with LV, but difficult, and it took us a while to get the tools in place to visually diff VIs.
  
• later applicability. using the language features I learn when programming my FIRST robot is knowledge with a limited lifespan. I was a decent S/360 and VAX assembler programmer once, but those skills are no longer applicable. The underlying concepts are still useful, and the some things (like learning to use an SCCS with good tagging features) are things that last decades. The OO concepts I learned with Borland Pascal is still useful with Java and C#, though the language is no longer widely used. yes, the syntax and APIs learned in FIRST do help with college and the first job, but don't bank on it for longer than that: the underlying concepts you learn carry you past that point, and you'll learn those regardless of language. How much of what concepts you learn will probably depend on language: LV and Java/C++ emphasize different concepts.
  
  
• Greg makes a *great* point: it's a sad day when we don't have a choice. I'm happy my team moved to Java (and they are *very* happy). If the school offers a C++ curriculum, then I'll take my old brain in, have it stretched, and support the students as they learn that. If my team gets smaller or I move to a different team with 2 or 3 programmers that are rabid about LV, I'll support them.
  

so the ultimate answer?

"it depends"...

don't just ask "what's best?". that's a religious war.

it's "we have this many programmers, they have this experience, they are this open-minded, we have this CS program at our school, our robot is this complicated, our workflow looks like this, and <insert more variables here>. What are the pluses and minuses of LV, Java, and C++ in our situation?"