[DFTF] Drinking from the firehose...

[Jim Zondag]

Labview vs. C++, vs. Java.

This is again very much a matter of preference.
Personnally, if I were working alone by myself, I would use C++. I know C way better than any other language.
But since the whole goal of FIRST is to teach people things, we use Labview.
The Java users are the smallest group, and we have never really considered this, mostly because we know C and LV so well.

I find that, when properly constructed, a well made Labview VI is much easier to explain to students than a chunk of C code.

One thing I will say....Labview makes hard things easy, but sometimes makes easy things harder.

Example: if you want to compare two items and act if they are equal or not, you can do this with just a few keystrokes in C:
(x == y) ? a : b;
While in Labview you need to wire up a equal block to a select block, and a simple operation looks a bit like speghetti.
However, in Labview you can often bring in a single VI block which encapsulates enormous amounts of complexity. Example, I have a single VI function we made once called "Crab", which included all steering and wheel speed code for a four wheel independent steer crab drive system in a single block. The key to sanity in labview is proper style, annotation, and encapsualtion to prevent too much spaghetti. There are tons of great opensource labview VIs out there for almost anything you can think of.

Some other benefits: the Labview support is better, I think because there is a larger community using it. Labview is more or less designed for rapid code construction, so it is good for iterative developement.

To me the biggest benefit of Labview is the fact that it is an instrumentation language. It is not really a true programming langauge and some do not like it for this reason, but in realilty, we are really not trying to do software engineering in FIRST anyway. In FIRST, we are not trying to develop a highly optimized, compact piece of code; we are trying to get a robust solution as fast as humanly possible. The ability to instrument your code while it is actually running is extremely powerful once you learn how. We never need any external instumentation at all anymore....if we need an oscilloscope, just add one to the front panel, if we want to record data to a file for later, then just add a file block to your VI. These things are super easy in LV.

That said, a good coder can make a great robot in any of the 3 language options.

My $0.02

[Alan Anderson]

Originally Posted by Jim Zondag

Example: if you want to compare two items and act if they are equal or not, you can do this with just a few keystrokes in C:
(x == y) ? a : b;
While in Labview you need to wire up a equal block to a select block, and a simple operation looks a bit like speghetti.

I like spaghetti better than oatmeal. You can straighten spaghetti so it looks nice, but oatmeal tends to remain mush no matter how much whitespace you sprinkle through it.

Seriously, if you think a single wire between two blocks (along with the four inputs and one output) looks like spaghetti, you're doing something wrong. This is not an example of LabVIEW making it harder to do something easy. Using the keyboard to type C/C++ is faster than using the mouse to draw using LabVIEW, and compiling a C/C++ program is faster than building a program in LabVIEW. But for someone who isn't already highly skilled in a text-based procedural language, my experience is that having a working program using LabVIEW comes sooner.

This opinion comes from someone who is highly skilled in text-based procedural languages, and who is a relative newcomer to graphical dataflow languages. I just find LabVIEW to be a lot easier to use for the kind of things necessary for FRC robots.