PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

[davidthefat]

Originally Posted by AustinSchuh

I generally recommend C++ to people who are experienced with programming, and Java to most everyone else. My experience with Java has been that it's design choices make bugs in Java code easier to find. My biggest complaint about Java and C++ is that it's hard to get data back from them in a visually easy way to use.

We've been using text files to store constants recently. So, it's really easy to change constants and they stick across reboots. Edit it on the local machine, and run a script to FTP it up into place.

Just cout or printf() or System.out.print() out the stuff you need, that has proven to do me well, no need for fancy GUI

[AustinSchuh]

Originally Posted by davidthefat

Just cout or printf() or System.out.print() out the stuff you need, that has proven to do me well, no need for fancy GUI

I challenge you to tune a PID loop with only numbers streaming by. It's probably slower than writing code to plot what's happening yourself and then use the plotting software.

I agree with you that some problems can be easily debugged with prints, but there are other problems that are incredibly hard to debug with prints.

[davidthefat]

Originally Posted by AustinSchuh

I challenge you to tune a PID loop with only numbers streaming by. It's probably slower than writing code to plot what's happening yourself and then use the plotting software.

I agree with you that some problems can be easily debugged with prints, but there are other problems that are incredibly hard to debug with prints.

fstream it, write it into a txt file and read it after to debug... But still lots of numbers

[apalrd]

Originally Posted by davidthefat

fstream it, write it into a txt file and read it after to debug... But still lots of numbers

Or you could use LabVIEW and draw a graph of the data vs time in real time. Or just probe the variables as you want to see them.

As for your next post, as for the usefulness of C++, many tasks are being replaced by different languages. Look at the Unreal Engine. It does most of the work in UnrealScript, not C++. Look at some Source mods (notably Gmod) - they use Lua for scripting on top of a C++ back end - so the end user only ever works with the Lua end. Real things use a variety of languages, trying to argue that yours is "more used" is useless. Each language is used where appropriate, and will be determined by the user. If you like C++, use it. Don't complain about having to sift through all of the printf's that come with it.

[davidthefat]

Originally Posted by apalrd

Or you could use LabVIEW and draw a graph of the data vs time in real time. Or just probe the variables as you want to see them.

As for your next post, as for the usefulness of C++, many tasks are being replaced by different languages. Look at the Unreal Engine. It does most of the work in UnrealScript, not C++. Look at some Source mods (notably Gmod) - they use Lua for scripting on top of a C++ back end - so the end user only ever works with the Lua end. Real things use a variety of languages, trying to argue that yours is "more used" is useless. Each language is used where appropriate, and will be determined by the user. If you like C++, use it. Don't complain about having to sift through all of the printf's that come with it.

Well, those are different, they are game engines, I wanna be the ones making the engines... There is a difference, even if its scripted in Lua, its core is C++, its the C++ that uses the Lua SCRIPTING (Note SCRIPTING) language to interpret the game.

[kgzak]

I use LabView but I also know C++. I started programing in Visual Basic, joined the robotics team knowing very little about programing. My second year I picked up LabView and programed a basic robot in 3 hours. All it did was drive and shoot and had timers for the shooter but it took us to nationals. This was last year, now we have very advanced code that helped us win the Quality award at West Michigan.

[davidthefat]

Originally Posted by kgzak

I use LabView but I also know C++. I started programing in Visual Basic, joined the robotics team knowing very little about programing. My second year I picked up LabView and programed a basic robot in 3 hours. All it did was drive and shoot and had timers for the shooter but it took us to nationals. This was last year, now we have very advanced code that helped us win the Quality award at West Michigan.

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

[Azores]

I programmed our bot this year in Java because it's what I already knew best, so I figured I would use it so I'm not spending time learning to use another language instead of actually writing code or helping to actually construct the robot. Originally the programming team for us was planning on using C++, but when everyone else ended up not doing any programming...

[Radical Pi]

We have 2 programmers (including me), both of us were already fluent in C++ when we joined the team, so there was no argument over what language to use. I have done a fair amount of work in LabVIEW though (dashboard, some NXT programming before I discovered NXC), and I still prefer C++ and other text-based languages too.

On the argument over which language is better, I'd still have to go with C-style. In terms of useability, LabVIEW winds (it's by far the easiest to pick up), however in the more technical aspects it starts to fail. Have you ever looked at a disassembly of a LabVIEW program? I have (for NXT), and it does not look very good. I compared it side-by-side to a disassembly of an NXC program that does the exact same thing, and, even on a VM specifically designed for LabVIEW, the C code is so much simpler. The problem? No optimization. Lots of messy things show up in the LabVIEW that are just totally unnecssary for the operation of a simple program.

This of course, is not meant as a disrespect to LabVIEW. I'd imagine that during the switch from ASM to C there was the exact same argument of asm being so much more efficient than the C equivalents. What made the final difference? We figured out how to optimize the assembly so that the advanced structures of C took as little code as possible, and now it is super-hard to outperform C code in asm and still get a great program.

LabVIEW certainly has a future. It just needs that same time to mature and be able to match the output of the more established languages. Simple numbers can show this need. Earlier in the topic, I saw people talking about ~3 minute builds and downloads for LabVIEW. In C, I don't think I've clocked a full build and download in more than 45 seconds. Usually much less (on a pentium III to boot). Give LabVIEW time to become a high-performance language. Maybe not for the current generation of programmers, but give it 20 years, and I wouldn't be surprised to find dataflow languages creeping into our game engines (assumming the GNU guys get their hands on the language. It's a bit too pricey at the moment)

[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.

[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