PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

[Egg 3141592654]

It really depends on the task. I myself know Labview and Java like the back of my hand, and I know the very basic things about C++ (not enough for a robot). I have chosen Labview the past two years only because it is much easier to debug and understand core concepts for beginners. Next year, our team is moving onto Java, only because, as a long time text coder, Labview was very confusing to trace.

In terms of performance, our Labview takes FOREVER to deploy and build, but there is no noticeable lag difference between the two when they are in the robot and running. C++ could potentially be a bit more frugal with memory to decrease junk code, but that depends who is sitting behind the computer monitor. I say it depends on the task to determine which is the stronger language to code in.

[mathking]

I will offer another plea to be open minded about languages when you make decisions, and listen to your mentors, many of whom have a significant amount of experience in programming.

As for Lab View not being real programming, put that right out of your mind. (I have always been impressed with LabView, and the first time I saw was more than 20 years ago.) I have been teaching CS for a while now, and I know that one of the constant "discussions" in computer science education circles is whether to start students on Assembly programming or not. I count myself firmly in the "not" category here. Learning to program is about learning how to break a problem down into smaller problems, finding algorithms to solve those problems, translating those algorithms in instructions the computer can understand and then debugging. The last step takes an order of magnitude more time than all of the others. Too much detail at the start tends to make you worse, not better, at programming. For learning the ins and outs of programming a robot LabView is a fine choice. It is really good for modeling and controlling embedded systems. If you are of the "I would rather not use that particular front end, I would rather use the 'real stuff' do my own C programming" consider that someone has to write the C compiler (a task you will likely have to undertake if you go far enough in studying CS). So why are you looking down your nose at using something that "was probably coded in C anyway" when you are just using something that was ultimately coded in Assembly, which is not itself really how the computer works by the way.

As for language choice, what you are familiar with will tend to be what you favor. But one job of a mentor (and a main job of a teacher) is to help you grow intellectually. One good way of doing that is making you learn something new. Even better is writing code on a couple of platforms and evaluating to see which is better for what you need. This year we developed code for both LabView and Java. Our decision this year to ultimately choose Java over LabView was due to our desire to use CAN, which was much easier in Java than LabView. But this doesn't mean that Java is superior, just that it served our purposes better.

I first learned programming in Fortran, then in BASIC. My first job programming was in C. I would say that C/C++ is what I am most comfortable using for my own coding, although teaching AP Computer Science has made me pretty comfortable with Java. If I am writing a simple program for myself I will often write it in Java just because it is easier to make a simple GUI and get it working. But one thing I tell my students is that they should never make their decisions about what language is best while they are in high school based on their perceptions of the real world. Even if their perceptions are accurate, what they learn in high school will not be what they use for most of their lives. When I was in high school (early 80s) my programming teacher told us we really needed to learn COBOL if we wanted to ever be employed in the field. So I did, and have never really used it. She wasn't wrong about the field at that time, but it changed. There was a big upsurge in COBOL jobs for a while leading up to Y2K, but now they are going away fast.

Now that I am at the end of my "open yourself up to new experiences" sermon, my two cents about language choice. I find that Java has a lot to recommend for this kind of robot programming. The way Java handles events, threads and exceptions is straightforward and easy to implement. It makes for much more robust code than typical C++ code. As for Java being filled with "fluff," most of the so-called fluff is just a standard implementation of coding standards that you will be forced to use by an employer if you ever code for big projects in any language.

[synth3tk]

I don't know (or care) if it's "the best", but we used Java. Our three (3!!!) student programmers either left, or didn't return, and none of the freshmen had no desire to learn programming at all. So I was stuck with the role. While we had default/leftover code from previous years written in other languages, myself and the team mentor decided to use Java. Randomly.

I'll tell you what, though, I knew absolutely nothing of Java as of January 9th, 2010, beside the fact that it's a programming language. That first week of build, I started learning the syntax, rules, and studied the default code. By week 4, the robot drove, and the pneumatic kicker worked. Had I been given more than 2-3 days of exclusive access to the robot, I probably would have had a nice autonomous working.


Also, quick note, never count out other languages, ever. Sure, you may love the most popular language used, but knowing X or Y may cost you a job/project.

[Tom Line]

Originally Posted by apalrd

We like LabVIEW because we can do real-time analysis of things without re-downlading. Like making graphs vs Time of data points, probing data, and changing cal points. However, the largest negative I have is the build and download times. I once timed a build at 2 mins 41 seconds. The downloads are more reasonable, at around 1 minute. Overall, I would prefer LabVIEW over C++.

Ding ding ding. This is exactly why we promoted labview to beta teams over C++ etc.

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree with the builds and downloads taking a bit, 4 minutes is pushing what you can handle during eliminations.

[virtuald]

Originally Posted by Tom Line

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree, having real time feedback on variables (and being able to provide that feedback as well) is an incredibly powerful tool. Thus why I created WebDMA, so you could have the same type of functionality in C++ -- incredibly simple to use. I haven't gotten around to adding graphs yet, but anyone reasonably competent in javascript could do it without too much effort.

http://code.google.com/p/webdma/

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

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

[BEEKMAN]

Originally Posted by davidthefat

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

correction, the write another C# program to make a graph of the data!!! now you have 2 languages!

[byteit101]

Originally Posted by BEEKMAN

correction, the write another C# program to make a graph of the data!!! now you have 2 languages!

Like the ZomB Dashboard! (Its in C# and uses graphs!)
http://www.chiefdelphi.com/forums/sh...t=82612&page=2
http://firstforge.wpi.edu/sf/projects/zombdashboard

We used these graphs to tweak our drive system to perfection