[Patrick Chiang]

Originally Posted by Arhowk

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

Not my experience. (And I know Java and C++ way more than LV.) Testing and debugging vision in Java or C++ has been a pain. It's a visual thing, so it makes sense a visual language does it better. The real time debugging features are pretty convenient too.

Originally Posted by Phalanx

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

Comparing number of bugs reported on a single bug tracker is a pretty poor metric. It could be there are less people using LV, or maybe the opposite is true. It could be people using LV are reporting their bugs elsewhere. It could be because the Java and C++ bugs were solved 2 months ago but the people who develop for those libraries received the bug reports on another platform and didn't close them here.

The FIRST tracker may be "official", but I personally don't know anyone who uses it to report bugs. If anything, comparing the number of problem threads on Chief Delphi and replies would be a more comprehensive metric for which tool is more stable.

Originally Posted by Phalanx

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

Hint: It's not the library, it's not the JVM, and it's not the cRIO. In all my 5 or 6 years of using FRC Java, I have personally never had to solve a problem that had to do with the library or the JVM or the cRIO, and I've never had the library behave in a way that is illogical for me. For me and the majority of teams I've helped or talked to at competitions, the library is never the problem.

Does this mean that the library is bugless and completely stable? No, but it's a much smaller problem than people seem to be making it, to the point where it's not a concern for most teams that will be using the common functions of the library.

Originally Posted by Phalanx

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

Here's the thing though: FRC is designed to emulate real life engineering where knowing the vendors is important and you need to have fire drills on who to call if something fails, but for most teams, that's just not how it is.
The cRIOs, libraries, JVM...etc are all fairly reliable. The biggest points of failure are usually the wiring on your robot or the code that you wrote. Pointing fingers at vendors is much less helpful than being able to debug and solve your problem immediately, which I'll argue that text based languages are better for.

Originally Posted by wt200999

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

You can have spaghetti code in any language. It's just more literal "spaghetti" in LV.
I wouldn't say it has a steeper learning curve. For a all the basic functionality on top of a robot (without fancy custom steering code, PID, or vision...etc), you can learn to program in LV before you learn why you should be setting the value of the jags to a double in Java or C++. Unless, of course, you already knew a text based language.

Originally Posted by wt200999

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Not even close. Say we have a robot with 4 jags, and each need to be controlled by a separate joystick. Don't ask why, the team needs it done now. In Java, the project takes 5 seconds to create, I can write up the code required in 30 seconds (conservatively), deploy to the robot in 52 seconds, go get a soda, and be back before the LV project is even fully created.

Comparing the code production time, I'll assume you're fairly fast and don't make mistakes in LV. It takes you at least 2 blocks for each jag, open and set, then you need 2 blocks for each joystick, open and set, then for each you need to specify the port, module, and channel constants, and then wire them all together.
Then, copy and paste 4 times and change each constant. If the whole thing is in a while loop, you also need to clean the broken wires and then rewire each time. Even if each palette you need is already pinned on the side (or using quick drop), I have a hard time seeing anyone do all that in 30 seconds, not to mention LV sometimes needs to open up new files whenever you access new tiles for the first time.

Originally Posted by Greg McKaskle

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

Come on, now. There are things that are easier in LabVIEW (like debugging vision as you said), but for loops and case statements are not them. How much does it really take to create a for loop in text code? 2 seconds? Creating and hooking up the constant true/false conditional in LV takes more time, and finding the comparison operator in LV takes time too.
Imagine if you had to do a perfectly reasonable conditional like (a && (b || c) && (d < e + f * g)), the race is over for LV at that point.