PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

[Dkt01]

Wind River is fast to build, but has a bit of a learning curve for those who know little C. I like LabView. It is easy to get used to, but it takes FOREVER to build. I've never tried Java, but I've heard it runs slowly on the robot.

[davidthefat]

Originally Posted by Dkt01

Wind River is fast to build, but has a bit of a learning curve for those who know little C. I like LabView. It is easy to get used to, but it takes FOREVER to build. I've never tried Java, but I've heard it runs slowly on the robot.

IDK but I didnt think Java was slow as I thought it would be

[CVassos]

I've known C++ a lot longer than I have Labview, but when they introduced it to FRC I decided to try it and learn a new language. Which was great because it's just a new way of doing things. As for Labview not being a "real" language used in the "real" world, last summer I was doing research and while I was programming the device I was working on with a combination of Verilog(a hardware descriptor language) and C++ I had some friends in chip testing who were doing some "serious" programming using Labview. It's a language that is used widely by scientists and engineers. Although personally I prefer to code in C++

[AmoryG]

Originally Posted by davidthefat

But I will bet you C/C++ was used to program that LabView

Deep down, isn't Java just C/C++ code as well? It means squat that LabView is built off of another language. It's still a language.

[EthanMiller]

My opinion is all this contains.

I used Java to program the robot this year. Last year, I used LabVIEW. And to be honest, once each was on the robot, I didn't see any difference in performance. We also didn't get any complaints from the drivers.

I'm probably going to try C++ next year.

I'm not an experienced programmer. I started programming on the TI graphing calculators, with the built-in BASIC-like language. Moving to LabVIEW was something different, and JAVA the same. And I can say - again, my opinion - that for this application, I didn't see that one was particularly better than the other.

I'm probably still going to learn Java and C/C++ for programming for the computer. LabVIEW programs can run on a computer, but that doesn't mean it's inexpensive to do so.

Thus, does being proprietary and costly make a language better or worse? Or does it merely make it more exclusive? And, is exclusivity a bad thing?

And as for LabVIEW not being programming: My opinion is that anything that is compiled into native code and executed on a computer is a programming language. This may not be accurate - I'm in 10th grade and starting programming, so correct me if I'm wrong in that definition - but LabVIEW fits it, and so to me is real programming.

[Robototes2412]

Java is faster than labview

dissassembled, labview code makes random calls that waste cpu cycles. Java code doesn't

[Greg McKaskle]

Bravo Ethan Miller. Very well said. That is the sort of attitude that makes it rewarding to work with FIRST.

Greg McKaskle

[Greg McKaskle]

Java is faster than labview

dissassembled, labview code makes random calls that waste cpu cycles. Java code doesn't

Can you elaborate on what led you to that conclusion? Better yet, do you have benchmarks?

Greg McKaskle

[kgzak]

Originally Posted by davidthefat

The judges judge your code too? They never came over and asked me to show them my code...

Kind of, We told them how we used the camera to track the goal and how we can go an exact distance in autonomous.

[Chris Hibner]

What is "easiest" and "best" is really a matter of what it is that you're trying to do and where your experience lies.

Experience is a huge factor. Ask anyone in the world what the easiest spoken language is, and I'm sure almost everyone will answer that their native language is the easiest, because that's what they have the most experience in, and that is the language that they "think" in.

I know more computer languages than I have fingers to count them on. I have enough experience with languages to know that a) every language is "illogical" or "difficult" or "hard to follow" in many ways just because you're not used to thinking that way when you're new to it, b) every language becomes pretty cool in its own way once you learn the ins and out, and c) there are "different horses for different courses".

So what is "easiest"? It depends on the task at hand. If you have absolutely no programming experience and you want to be able to do some simple things on your robot, LabVIEW wins hands down (at least in the three choices given here). There aren't a lot of syntax peculiarities that you have to learn before you can get going. If you want to do some ultra-complicated stuff, then you can have a debate that no one will ever win.

If I have any advice, it's this: if you have a group of people that are highly experienced in one language, stick with it since that will be the easiest for you. If you have no experience whatsoever, go with LabVIEW.

[Imadapocalypse]

Personally java seemed to be the best fit. Being my first year as a programmer it would be natural the the first would be my favorite. But after seeing our programmers constantly struggle with the labview software it makes sense to go back to text based programming because it has more real world applications. The only problem I had with java was the unclear documentation of classes. Sometimes it was difficult to understand what exactly parameters were asking for. Otherwise it was very easy to code, simple to troubleshoot, and a breeze to build and run.

[gvarndell]

Originally Posted by davidthefat

The judges judge your code too? They never came over and asked me to show them my code...

The judges want to know if (at least) some of the student team members know anything about that machine that's playing on the field -- including the software.
For obvious reasons I think, it doesn't reflect well on the team if none of them do.
And it goes beyond the technical.
At one regional we attended, a judge came up into the bleachers and asked me (I am old and my team affiliation was apparent owing to the team T-shirt I was wearing) if I had picked our alliance partners for the eliminations.
I told her she'd have to talk to the captains about it because I had given it very little thought.
Somehow, I think that was the answer she was hoping for (and it was the truth).

[FRC4ME]

My team switched to Java this year, primarily because it is the language taught in high school CS courses around here, and I am very glad we did. It is so nice to not have to explain memory management to the students or spend hours debugging a null pointer problem when the best the compiler can do is say, "something went wrong somewhere...probably." Most of the things you do in Java just "make sense," with very few syntactic quirks that seem unnecessary or silly to new students.

My main gripe with C++ is that it gives you far too many options. Should you pass by reference, pointer, or value? Here a hint; none of the three options do everything you want. The 2010 revision of the C++ spec will add another one: move reference (denoted by var&&)...this is getting a bit ridiculous. When defining a new class, you better write the copy constructor, destructor, and assignment operator (and move constructor in the new revision), or the compiler will do it for you (almost always incorrectly). Be sure to maintain exception safety in your constructors - 20% of my favorite C++ book is devoted to that subject. Put declarations in the header file and definitions in the source file; unless they're inline or templates.

And if that's not complex enough for you, with a Turing-complete preprocessor and template system, you can effectively rewrite the language (see: Boost libraries).

Java seems to be much better in the straightforwardness regard. Although I wish we weren't limited to CLDC 1.1: it has some idiosyncrasies of its own. ((Integer)vector.elementAt(index)).intValue is not an intuitive way of extracting an int from an array.

[wireties]

I've been doing this (software/hardware design) for 25 years using languages from assembly through C/C++/Pascal/Modula to PHP/Python and Perl. I've also used a few code generators which is what I think LabView really does. I am pretty sure LabView actually produces C (and maybe C++) source then compiles it. I know it did 15+ years ago. Albeit at a higher level, I too think LabView is really a language (and a very complex one at that) and NI is an awesome company.

Bottom line - you use different languages for different reasons at different times. To mitigate technical risk, it is wise for FIRST teams to use the supported language the mentors know best. Otherwise use LabView because you'll get the best newbie support from NI.

Languages like C and C++ are more powerful and normally faster in embedded systems. They make good programmers better but bad programmers intolerable. The VxWorks kernel is written in C and one can make C literally do anything on a FIRST robot. Java and LabvIew are another step removed, Java goes through the J2ME and LabView is (at least partially) a code generator. These abstractions have potential huge benefits but nothing is free. They are (at least a little bit) slower than C.

That is my 2 cents.

[Greg McKaskle]

I've been doing this ...

I agree with your overall post, but to correct a few details -- LV 1.0 was interpreted, but ever since LV2.0 released in 1990, it has been compiled. It compiles to machine code for various architectures. It doesn't need to generate C source. It doesn't do so primarily because C is such an unfriendly language for multitasking.

NI does sell an add-on module which allows targeting a wide variety of 3rd party embedded devices by generating C source and then using the vendor's C compiler. It was introduced maybe eight years ago, well after RT. That is not how RT works or how the desktop works.

Greg McKaskle