Java VS C++ || The Final Decision

[LavaEagle]

LabVIEW is an irrelevant language here!

[davidthefat]

C++ I find Java to be a language that is similar to C++ but with traning wheels

[apalrd]

If I had to choose between C++ and Java, I would choose C++ for robot programming:

1. The gigantic advantage Java has over C++ is that it can make pretty GUI's. However, that is completely useless in cRio programming as there is no GUI interface.

2. This year, Java was on its first year and C++ was on its second, however the old control system has been using C since 2004. C/C++ is much more proven and tested in FRC robotics as of now then Java.

3. I already know C++. I don't already know Java. I also know and like LabVIEW.

[LavaEagle]

Originally Posted by apalrd

If I had to choose between C++ and Java, I would choose C++ for robot programming....

You sir make a very good point.

[timothyb89]

Originally Posted by apalrd

If I had to choose between C++ and Java, I would choose C++ for robot programming:

1. The gigantic advantage Java has over C++ is that it can make pretty GUI's. However, that is completely useless in cRio programming as there is no GUI interface.

2. This year, Java was on its first year and C++ was on its second, however the old control system has been using C since 2004. C/C++ is much more proven and tested in FRC robotics as of now then Java.

3. I already know C++. I don't already know Java. I also know and like LabVIEW.

1. Trust me when I say that Java is *much* more capable than that. Desktop Java, as in version 1.6 with standard libraries is considerably more capable than vanilla C++. Even with the limited version you get on the cRIO (Java 1.3 with J2ME libraries) you can still do plenty. I have plenty of examples if you'd like .

2. With a new and different environment (the cRIO) you can hardly call it 'proven'. The (completely) new C libraries only have a year's head start on their Java equivalent, and having used both, I can say that both work very well.

3. A valid point, but I'd certainly recommend you give it a try- in most cases the syntax is identical or even simpler than a C/++ equivalent so the learning curve is actually quite small.

Originally Posted by Alan Anderson

So is the provided FRC dashboard application.

That doesn't make it good. Trust me when I say that's one of the most inefficient programs I've seen in a long time. I honestly feel bad for the processor on our XO laptop while it (the dashboard) is running- the CPU usage shoots up to 100% rendering something that should barely take any CPU at all.

My opinion on LabVIEW: It may make coding convenient or easy, but that doesn't make it better than other tools.

[kgzak]

Originally Posted by LavaEagle

LabVIEW is an irrelevant language here!

How is it irrelevant? It is a programing language with the same, if not more potential than the other programing languages. Our team uses LabView.

[Alan Anderson]

Originally Posted by LavaEagle

LabVIEW is an irrelevant language here!

The makers of the cRIO would probably disagree about that. The FPGA (the part that does all the "real work") is programmed using LabVIEW. So is the provided FRC dashboard application.

For what it's worth, Team 45 uses neither C++ nor Java.

[LavaEagle]

Originally Posted by Alan Anderson

The makers of the cRIO would probably disagree about that. The FPGA (the part that does all the "real work") is programmed using LabVIEW. So is the provided FRC dashboard application.

For what it's worth, Team 45 uses neither C++ nor Java.

I apologize for disregarding LabVIEW. Wasn't my focus.

[biojae]

As much as I like C++, Netbeans was an easier IDE to use.
Some of the things that made it easier were:
- Integrated Netconsole, Serial comms without a long cord, (connecting to the remote server never worked for us)
- Automatic reboot on download, when not using the debug mode, this saved lots of time
- Automatic file uploader, uploads the correct program file without going to a configuration page even when changing projects

Though, it seemed that there was a memory leak somewhere which would limit us in how many times we could upload / minutes open before we would have to restart netbeans.

And library support was a little lacking this year.
Only the vision libraries that were needed to get the vision tracking were ported.
To access any other parts of the NIvision libraries, JNA (Java Native Access) was required, (Writing a method in C++, compiling it in windriver, and then uploading it)

CAN support for the closed loop modes (current, position, speed) for java was the last language implemented, with a gap between Labview and C++.

But, even without all of the libraries, Java was perfectly capable language for programming the cRIO, and FRC robots.

[AustinSchuh]

My biggest complaint with Java on the cRIO is that they ported a non-realtime version of Java, instead of a realtime version.

[Robototes2412]

I would be overjoyed to use C++ for robot programming,
IF THEY TOOK THE TIME TO MAKE IT COMPILABLE FROM LINUX, FOR THE LOVE OF CHRIST ITS GCC

edit:

Wow, i was angry.

could someone please <code> a makeFile from the C++ stuff? I think I can get C++ working on linux if i have a makefile.

[Kitmor]

I believe that both C++ and Java are equally capable languages for the type of robot programming that we are doing in FRC. So what it comes down to is a matter of personal preference.

I personally have a dislike for all interpreted languages, it just seems like a clumsy to me. I have spent about the same amount of time working with C++ as I have with Java, and I personally find Java a more frustrating language to program in. I understand that part of the goal of Java was to force an object oriented design of the programmer, and while I like this concept, I dislike how restrictive it makes the Java language.

I have had teachers that raved about Java, saying it's the best thing since sliced bread, and while I respect my teachers.... I have to respectively disagree. Java is possibly a good learning tool, but for making clean, efficient programs, it's just not the thing for the job.
-Kit

P.S.
I would also have to disagree about the strong point of Java being it's GUI abilities. If you take and C++ compiler and add on a nice graphics library like QT, Java is no match. The language is just all around clumsy.

[mwtidd]

Originally Posted by Kitmor

I believe that both C++ and Java are equally capable languages for the type of robot programming that we are doing in FRC. So what it comes down to is a matter of personal preference.

I personally have a dislike for all interpreted languages, it just seems like a clumsy to me. I have spent about the same amount of time working with C++ as I have with Java, and I personally find Java a more frustrating language to program in. I understand that part of the goal of Java was to force an object oriented design of the programmer, and while I like this concept, I dislike how restrictive it makes the Java language.

I have had teachers that raved about Java, saying it's the best thing since sliced bread, and while I respect my teachers.... I have to respectively disagree. Java is possibly a good learning tool, but for making clean, efficient programs, it's just not the thing for the job.
-Kit

P.S.
I would also have to disagree about the strong point of Java being it's GUI abilities. If you take and C++ compiler and add on a nice graphics library like QT, Java is no match. The language is just all around clumsy.

I have found that its "restiveness" is actually one of its strengths, especially with regards to FIRST. C and C++ take longer to debug, and as has been discussed in other threads, the biggest restriction to programmers is the time they get with the robot, so being able to debug quickly is critical.

Java is certainly a pig of a language, but I also like using it for backends to an GUI. I use Flex (which is also a pig) but ports nicely now with Java since flash builder 4 and blazeds. I really like OO, especially from an architecture standpoint and flex brings OO development to web and desktop dev. So even though it is a pig, it is easier to debug and I find it easier to build with.

Then again from my experiences, people who love c and c++ hate flex.

(lets not get started on steve jobs.... )

[Greg McKaskle]

I don't really want to get involved in these food-fights about languages, but since LV came up, let me just clarify that the CPU usage of the dashboard is not something that you can blame on LV. Blame me instead. I made a mistake and the LV UI was dealing with overlapping controls the best way it could, doing offscreen drawing and extra redraws. That is what used the excess CPU.

Greg McKaskle

[mjcoss]

I have the team program the robot is all three languages. We then use the software that a) has the lead programmer at the event, and b) works the best. Each language has it's place. I personally believe that Java is not appropriate for embedded systems. Labview is great for debugging, and we use Labview as a diagnostic tool. Labview is easy for many people to grasp, and they can get up and running quickly. Java is what is taught in a lot of high schools in the AP classes. So at the end of the day, you use what the students, and mentor feel comfortable with.

One major issue is that each language provisions the CRIO slightly differently, which leads to different behavior on the part of sensors, and even something as simple as communication with the driver station.

And as far as using Linux to program the bot, it is doable, but it's not simply setting up a makefile. You need to use the VxWorks compiler, and create a kernel module. Not sure that it's worth the work.