FRC Java or Labview?

[teku14]

This is a classic debate on CD.

As many of the others have stated on this thread, you should go with the language that you are most comfortable with and further your efforts in that. But I do want to dispel one notion about Labview as though it is some kind of a regression. From what I have seen, labview in FRC is atleast as powerful as Java is. Yes, it has a low entry point making it very accessible to newer teams and programmers but it also has a very high skill cap. Several veteran teams use it and have had no trouble achieving what any Java or C team has. I would also like to point out that Labview is used in many applications beyond FIRST such as indisutrial automation and testing. While Java is the more popular and more widely used language in the real world, it is also undeniably been on the decline.

That aside, there is no difference in what you can achieve with Labview or Java in FRC and the choice should be based solely off of which your team has the most experience with and is more comfortable with. I see that while you all have used Java thus far, your mentors seem to be proficient in Labview. I know that mentor expertise is the deciding factor for many teams in their choice of language so I urge you to keep your options open.

[GuyM142]

I think that you can be successful with either language,
Our team uses LabVIEW and we keep using it because it was used since our rookie year and we gained experience with it.

I think you should consider the following things in your decision:

1) How many students on the team have already had a season using Java?
Experience is something you should maintain and a transition may be a struggle.

2) How many new students came with no programming experience?
As far as I know it's much easier to teach LabVIEW to new programmers.

3) Are there any mentors on the team that know Java or LabVIEW already?
Mentor support is always good, if you have a mentor that knows Java you should consider staying.

4) What programming languages does other teams use around you?
Getting support from other teams around you can help solve problems faster, even during build season.

Hope it helped,
בהצלחה

[Alan Anderson]

LabVIEW compile times are longer, but not prohibitively so. It only takes a matter of seconds to put compiled code on the robot.

LabVIEW seems harder for people who are used to a procedural language like C++ or Java. That's usually because they are trying to approach it using what they already know. Unfortunately, what they already know is largely inapplicable to dataflow languages and actually gets in the way. If you start out with the idea that you know nothing, you will find LabVIEW much easier to learn and use.

LabVIEW is simple to start out with. It is also very powerful. Its inherent parallel nature makes it easy to do some things which are difficult in other languages.

On the other hand, typical object-oriented features are not as deeply baked in, so common OO constructs aren't as simple, though again thats mostly an issue for people with a good background in such languages.

[GeeTwo]

Both Java and Labview (and C++, of course) have competed at the highest levels. The question is what is right for your team? How many programmers already know each language, how many mentors are comfortable in either language, and how many mentors are willing to learn the other?

We have been a Java team from 2012 to 2016, but we're looking at only one student who's done any significant programming being on next year's team. Our steady programming mentor for the first five years is backing out a bit (maybe more) due to marriage, moving, and a new job that will send him to sea in various places around the world.. If our new programming mentor wanted to switch to LV, this is probably the year we'd do it.

Repeating the bottom line - which is better is much more dependent on your internal capabilities than any abstract "betterness" of the program language. The only considerations outside your team should be online support. LV, Java, and C++ all have decent support on CD, but perhaps one or two of these languages has better local/hands-on support from nearby teams.

Play the ball as it lies.

[Joseph DeRoest]

I've been programming in LabVIEW for 4 years now, and would like to give you some technical details about it. As for Java, I'm actually learning it as I speak, so I can't be of too much help in that. Sorry.

Pros:

LabVIEW looks more simple for beginners because of the graphical aspect: wires connecting to blocks, drag-and-drop, selecting stuff by drawing a box around them, all of that is more familiar to people with no prior programming experience.
LabVIEW is amazing at running different parts of code in parallel.
There is A LOT of support for LabVIEW on Chief Delphi!
It is an industry-standard programming language.
You can drag-and-drop other teams' LabVIEW code directly into yours.
LabVIEW has many nice tools to help you when programming. For example, to help with following data transfer inside the code, there is a highlight function that highlights the data flow in ordinal fashion.


Now, LabVIEW does come with quite some quirks and annoyances...

Cons:
LabVIEW and trackpads DO NOT MIX! It basically requires you to have a mouse.
LabVIEW's version of vision processing has a bunch of lag (about a half a second).
The LabVIEW application has no tab interface; in other words, if you have 5 VI's open at the same time, you will have a messy conglomerate of 5 windows on your screen that you will have to switch between.
LabVIEW looks like a nightmare for those who have prior programming experience in a text-based language with its wires going everywhere, random blocks and boxes, etc.
Merging two VI's in LabVIEW is literally THE WORST! A VI-merging application is included in the FRC LabVIEW Suite, but it takes at least 30 minutes just to merge average LabVIEW code, and it may not even do it just the way you want it to, either.
It takes LabVIEW quite some time to deploy code to the robot. I had a weird issue in which the code would not deploy correctly, and in the end, would display a connection issue, so I would have to almost always deploy the code twice or even thrice.
Once you begin making more advanced programs, LabVIEW code becomes more and more complex. For example, my team this year has two cameras on the robot for driver vision, and we wanted to be able to switch between the two camera views at the push of a button. To do that, we had to dig reeeaaaly deep into the existing code infrastructure (roughly seven layers of SubVI's) and change several components. It took several hours of debugging just to make it work!
Debugging in LabVIEW can be time-consuming, mind-boggling, and overly complicated overall.


Once again, I'm sorry that I can't be of too much help when it comes to Java (yet...). If you have any questions, I will reply as soon as I can. Hope this helps!

[cnc4]

Thank you all for your answers, i really appreciate it.
I have one question, what support does Labview have with Git?
Or maybe there are other source control for it?

[phurley67]

We have been a labVIEW team of late and are planning on switching to Java, for two reasons.

The primary reason is a direct response to your last question. Using LabVIEW with version control is difficult. If you have a single developer or only a single development machine, LabVIEW has an integrated versioning system you can enable which will provide the "time machine" aspect of version control without any merging capability, which works effectively.

Once you want to have 5 different people working on different sections of code, we have found it difficult (not impossible) working in LabVIEW. In particular LabVIEW has a tendency to "change" VIs (like files in Java) whenever they are opened, even if you did not make a conscious modification. If developers are not exceedingly careful with their commits GIT (or any other optimized for text versioning system) will shrug and force you to handle the differences yourself. LabVIEW does come with a reasonably useful VI diff/merge utility which can be integrated into git/subversion workflows; however, we have had trouble properly utilizing it, especially compared to the ease with which git can handle merging text files.

Our second issue with LabVIEW has also been mentioned above -- longer/unpredictable deployment times. This is not the compilation process, but rather the way in which code is transferred to the RIO. We have experienced numerous communication failures, resets, incomplete deployments. I suspect this may have something to do with portions of our code running in fast loops, as I do not see the problem on freshly imaged RIOs or teams using very simple configurations. That said deploying new code should not be so significantly impacted by previously deployed code you are trying to replace :-)

Regardless both languages are capable of developing advanced robots and each has their own advantages (e.g. it is very hard to beat LabVIEWs ability to graph/visualize data on the fly during development).

Good Luck

[Coach Seb]

2016 was our rookie team and we had one programmer that ;learned LV on its own with help from a couple other local team. He did pretty good considering that he was pretty much on its own. Just graduated and we are now starting from scratch again.

I reviewed some data from FIRST and found that of all robot that connected to a field last year, 49% use Java, 35% use LV... remaining are C++ and a few Python....

I decided to check out Java... i love the Eclipse interface. I used Robotbuilder successfully to build a few small subsystems and so far i really like the test mode using the java Smartdashboard. Just that for us justify making the switch.

Our students are already learning basic Java programming as they are expecting the switch.

I did not successfully control a test robot yet... but i am confident that i can make it work... finding a lot of resources online. Hoping this will be a good move... only time will tell...

[teku14]

Originally Posted by cnc4

Thank you all for your answers, i really appreciate it.
I have one question, what support does Labview have with Git?
Or maybe there are other source control for it?

We use Subversion (SVN) with TortiseSVN. It's quite simple to use and gets the job done for us.

[marshall]

Originally Posted by cnc4

I have one question, what support does Labview have with Git?

A lot of teams use SVN. Git isn't officially supported by LabVIEW yet but I believe it is coming soon. We use LabVIEW with git though and we couldn't work without it. We're a LabVIEW team and quite happy with it. YMMV though.