PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

[krudeboy51]

WHICH SOFTWARE IS THE BEST AND EASIEST TO USE TO PROGRAM A ROBOT, AND WHY YOU THINK IT IS?:

-WIND RIVER C++

-LABVIEW

or

-JAVA

to start, i choose windriver c++, because its the only language i know lol

[davidthefat]

C++ is my favorite language, but I never used windriver, but I heard to was a $@#$@#$@#$@#$@# to use...

[gr8dragon]

I prefer C++ because its the first language i was introduced to.
I like Labview as it is not the same text coding I have been used to for a long time.

However we chose not to use Labview over Windriver because we thought that having a bunch of those connecting wires might get harder and harder to trace.
I guess I really haven't used it too much besides basic robot functions and one sensor.(Pot)

We kinda just said not to use Java and it was rather arbitrary.

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

[davidthefat]

Personally I wouldn't call LabView coding at all...

[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

Personally I wouldn't call LabView coding at all...

Then what is your definition of programming?

I personally define programming as using a language that is turning complete to get a job done. Using Labview fits that definition, so I'd personally call using it programming. I may not enjoy using the language, but I personally don't let that effect my view about whether using it is programming or not.

[apalrd]

Originally Posted by davidthefat

Personally I wouldn't call LabView coding at all...

LabVIEW IS coding. It's used often in the real world (although not on production things, many companies use it for testing and experimentation), its optimized to run on cRio's, can run on the FPGA too (although FIRST won't let us do that), has networked front panels, can execute C libraries (using Call Library Function), can run parallel tasks (multithreading) super-easily (try making two WHILE loops in C++ that run in parallel, you won't be able to do it as easy as you can in LabVIEW), the ability to make asynchronous calls easily (static VI ref + Invoke Node), built-in toolkits for PID, fuzzy logic, and toolkits available for many more cool things, through a number of sources, comparable to many C++ libraries. If you are just saying your language is better than LabVIEW, while I see how you could consider C++ or Java "real" programming, LabVIEW is real code too, it runs just as well, it is super-easy to debug, and it's alot easier to code then C++ or Java.

[davidthefat]

Originally Posted by apalrd

LabVIEW IS coding. It's used often in the real world (although not on production things, many companies use it for testing and experimentation), its optimized to run on cRio's, can run on the FPGA too (although FIRST won't let us do that), has networked front panels, can execute C libraries (using Call Library Function), can run parallel tasks (multithreading) super-easily (try making two WHILE loops in C++ that run in parallel, you won't be able to do it as easy as you can in LabVIEW), the ability to make asynchronous calls easily (static VI ref + Invoke Node), built-in toolkits for PID, fuzzy logic, and toolkits available for many more cool things, through a number of sources, comparable to many C++ libraries. If you are just saying your language is better than LabVIEW, while I see how you could consider C++ or Java "real" programming, LabVIEW is real code too, it runs just as well, it is super-easy to debug, and it's alot easier to code then C++ or Java.

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

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

[The Lucas]

Originally Posted by davidthefat

Personally I wouldn't call LabView coding at all...

When I saw this thread I thought "Over/Under 5 posts before some throws out this particular flame" Looks like it a push and I was right on. This argument is getting old and predictable.

My team uses C++ because that is what works best for us. All 3 languages are coding. I suggest everyone try to learn all 3 of them. Trying to argue that any one language is better for programming FIRST robots is a meaningless pursuit, it is all based on personal opinion. They certainly have their own pros and cons (which are fine to discuss) but all are equally capable. Try to focus on what you would tell a rookie team trying to choose between the 3.

[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

[davidthefat]

Originally Posted by The Lucas

When I saw this thread I thought "Over/Under 5 posts before some throws out this particular flame" Looks like it a push and I was right on. This argument is getting old and predictable.

My team uses C++ because that is what works best for us. All 3 languages are coding. I suggest everyone try to learn all 3 of them. Trying to argue that any one language is better for programming FIRST robots is a meaningless pursuit, it is all based on personal opinion. They certainly have their own pros and cons (which are fine to discuss) but all are equally capable. Try to focus on what you would tell a rookie team trying to choose between the 3.

I personally will tell the said rookie team to pick up a C++ book and read it and study and meditate on it, IMHO its way more useful in the real world out of the 3. If you learn C++, you pretty much know Java (except alot of the java specific stuff), won't take you very long to pick up on java. Plus most real world applications are in C/C++, like Operating Systems, Games, and tons of stuff.

[Greg McKaskle]

To anyone thinking you may be interested in a programming career or a Computer Science or Engineering degree, I'd encourage you to be open to, and in fact get used to, learning new languages. Learn how to compare and evaluate the features looking for the weak and strong aspects of the language. It is also good to learn how to separate the language, library, and environment elements.

Greg McKaskle