Java vs Labview

[alexander.h]

Hello! I'd like to hear your opinions when it comes to comparing Labview with Java. Thanks!

[MrTechCenter]

Well, they are very different. For a beginner programmer, Labview is great for learning programming logic, however, Labview has minimal application outside of FIRST. Java is great because it is widely used and will be a useful skill for anyone who learns it, however, if someone is just starting to program, they may have difficulty following the logic in Java. It really just depends on how much programming skill you already have, and how much you want to/are willing to learn.

[MrRoboSteve]

I usually recommend to teams that they use the language that is most familiar to their programming mentor.

As an aside, Labview is widely used in industry, it's not just a FIRST thing. A quick look at dice.com indicates they have >100 jobs listed with Labview as a keyword.

[themagic8ball]

LabView was used in the SpaceX Dragon capsule: http://k12lab.com/inspiration/spaceX.

Like anything, each has their pros and cons. You may want to try each one and see what you like better, and like Steve said, see what kind of mentor support you can get for either.

[JohnFogarty]

We teach our students java because it's the AP standard in Computer Science courses taught to high school students who choose to take the course across the US. Also, speaking from experience here, Java was the first language taught when I entered university as a freshman Computer Engineering student. Java is more widely used throughout the world in various computing fields than LabVIEW is at the moment. Therefore I find it to be much more "useful" to my students to have it in their skill-set.

Not to knock on LabVIEW since I myself started out programming in LabVIEW. However when it came down to editing small portions of code to do exactly what I wanted them to do, I found that it was much easier to do in Java. Plus I didn't have any software mentor support at all when I started FRC programming. I used the internet resources like Chief Delphi to find my way.

While I know that there are many jobs that you can get with knowledge of a language like LabVIEW, I would definitely say there are a multitude more for those with a background in Java. The automation and commercial industries seem to be taking an interest in LabVIEW because of it's easier to understand logical and graphical interface, but for someone who has no problem understanding programming logic. I find LabVIEW somewhat restricting. Now had I been mentored properly using LabVIEW as my beginning language I might feel differently, but you can't change what hasn't yet happened.

Just my two cents.

[mathking]

LabView is actually pretty widely used outside of FIRST. It is actually older than Java. As has been said, it is used primarily for control, automation and data acquisition applications. If you have students who have done FLL, making the jump to an FRC robot programmed in Java will not be difficult. That and the ease with which autonomous routines can be coded are two strong reasons for using LabView.

That said, we have been using Java since we switched from LabView in 2010. The reason is pretty much John said, the kids use Java in AP and IB Computer Science, so we have more Java capable programmers than LabView. As a computer science teacher (who has programmed and taught in C++ and Java) I find that Java's event driven programming paradigm makes understanding robot code easy when compared to using C++.

For me the biggest question to ask is do I have most capability (student and mentor) to support one language choice over the others. That trumps the relatively smaller differences in the capabilities of the languages. All three of the FRC programming language choices will allow you to do what you want with a robot.

[SoftwareBug2.0]

Originally Posted by MrRoboSteve

As an aside, Labview is widely used in industry, it's not just a FIRST thing. A quick look at dice.com indicates they have >100 jobs listed with Labview as a keyword.

In case anyone is wondering Java or C++ each show well over 10,000.

[Pi3th0n]

Team 900 is (almost) unanimously in favor of Labview. We used Java last year and had all kinds of trouble with getting the robot to actually move. We switched to Labview this year and our robot runs beautifully. Also, most of our programmers this year didn't have any experience with either language before the start of the year and they picked up Labview really quickly.

Of course, the number of programmers on the team at least tripled from last year to this year, so that could make a difference too...

[BitTwiddler]

Originally Posted by MrRoboSteve

I usually recommend to teams that they use the language that is most familiar to their programming mentor.

I'm not sure I agree with that statement. I consider myself as having failed the team this year by insisting on using what I know best (LabView). We had a couple of top-notch Java programmer students who lost interest because of my unwillingness to adapt. As a result I wound up doing all of the programming.

It seems to me that the mentors need to focus on whatever inspires the students and step back and let them go at it with occasional guidance when they go off on an unproductive tangent.

In the meantime. It's back to the Java tutorial for me.

My $.02

[Kevin Phan]

For me it all really depends on the programming team as a whole. I am currently doing AP computer science learning java, but I am using LabView to program our robot. Our mentor for electronics and programming used LabView for awhile and we continue to use it until there is a want to shift. I haven't touched the java libraries for the FRC competition, but it shouldn't be difficult to pick up after reading the documents about it. I hate the discussion of which language is superior to another, because it just pressures people to go with a language they're not comfortable with. Between java and LabView, I have no preference of one over the other. They both work well and to for me it comes down to how do you want to see your logic.

[Greg McKaskle]

I'm not a neutral party, but you asked for opinions.

For your team?
I honestly don't know enough about your team to be able to make a recommendation. So, I'd say that you should look at the capabilities and ambitions of your students and mentors. It is quite easy to go through tutorials and program your robot in each of the languages and make your decision based on which language provided more successful moments. That is an intentionally vague description since success means something different for each team. In some cases it is a better robot, in some a better learning opportunity. Some want the easy road and some want a challenge.

Also, a bit of background.
What is LabVIEW? LabVIEW is a relatively popular domain specific language. It is generally not free and not targeted to general computing domains. People who program with LabVIEW don't normally consider their job title to be "LabVIEW Programmer". They are instead a physicist, a mechanical engineer, a test engineer, a robotics engineer, etc. This is true of many professionals who use Java as well.

FLL, by the way, has exclusively used a version of LabVIEW since the beginning. ROBOLAB, NXT, and EV3 all ship with a version of LV for young kids. ROBOLAB was actually an iconic language written in LV, but wasn't really a LabVIEW equivalent language. Additionally, WeDo the jrFLL language was designed for even younger kids. It is a cross between Scratch and LV and was written in LV.

My actual advice?
It isn't which tool you choose. What matters is how you decide to approach the task of programming the robot. I am thrilled when students truly understand how their mechanisms work and how their code plays an integral role. If only it could happen more often.

Greg McKaskle

[Patrick Chiang]

We were trying to decide on whether to do the reverse thing for next year (switching from Java -> LV), so we did an informal survey of the teams at our regional this weekend. Surprisingly, out of 33 teams, 3 teams were using LV, 2 C++, and most of the rest Java. It blew my mind how popular Java has become since it was introduced less than a year before I came into FRC.

We have used both languages, and here is a comparison from my experience. IMO, they both have their merits but I personally prefer Java, so that's my bias.
Java:
+ Easier to find and solve fatal bugs. When program fails, Java tells you exactly where it does and what you need to do to solve that problem, sometimes even if you have never seen that error before. Code errors are easier to post onto Chief Delphi and stack overflow than screenshots of your LV wiring.
+ Faster deployment cycle. 52 seconds on ours to be exact, yes we counted. The 4 minute LV re-deployment on our laptop can be a major problem if we have to make even a minor change in the elimination rounds. LV is also a memory hog, which is ironic because a lot of traditional programmers consider Java a memory hog.
+ More intuitive for "software engineers". Lines of code and all. Taught in AP CS and college intro CS courses. I've heard that LV is more intuitive for EE people with its resemblance to circuit diagrams.
+ Source version control. In a good IDE, revert your code to what you had at 12:34 pm on May 6th, 2007. The "undo" function for LV is very limited, and you can't compare code differences on GitHub or something similar AFAIK.
+ Documentation. You can browse through Javadocs on a browser, whereas my experience with searching through LV functions is a nightmare-filled trip into a Windows Help style interface. In Java Netbeans, you can hit control+space and have it come up with every available function for a certain device, listed by contextual relevance.

LV:
+ Click and drag. How much easier does it get? If you know "line-based programming" before you learn LV though, it can be a nightmare.
+ Easier to tune specific functions (ex: PID). You can add a bunch of controls to the frontend without adding much code. Sometimes Java's Smart Dashboard just doesn't cut it.
+ More support at our FRC regionals. The control system advisor team is filled with NI people. For Java problems, be prepared to consult your neighboring Java gurus.
+ Easier to implement concurrency. You can easily do multiple things on the robot at the same time. On the other hand, you can easily do multiple things on the robot at the same time (which can be unintended). I heard some teams using the subsytems thing in Java have this pretty easy too, but have yet to try that.
+ Sample code. LV sample code for FRC beats out Java sample code hands down, especially in the vision department. It's been developed longer, and it just covers more.
+ Vision. LV is better for vision development hands down. The fastest way to develop vision code in Java is to do it in NI's software, then copy the filters back into Java. The simplicity of it all is really one of the best unmatched feature LV has over Java.

For a decision, as others have mentioned it may be important to consider what the mentors and team already know. However, both languages are easily learned, and the most important factor is by far the personalities of the programmers:

If you have hardcore software writing students who know every single shortcut key available on the computer by memory, think wiring and electrical are hardware problems, and have 4 different flavors of Linux installed on their home computer, making them do LabView is going to end up in disaster.
Actual quotes: "why the !#%$ are these being executed at the same time", "give me a break, I just copied and paste and now every wire is broken", "I hit the limit on the Undo button so we lost everything we did yesterday"

If you have hardcore electrical students who know what every number on their 8-function multimeter mean (yikes), can trace 6ft long PWM wires through spaces too small for adult hands, and dumpster dive for broken down lasers in their free time (all real life examples), Java may not be the best idea.
Actual quotes: "frigging red syntax errors everywhere", "why did it only work the first time", and my personal favorite "I think we fried Java"

[thmeans06]

Last year we used LabView and had nothing but problems. This year we used Java and out cRio crashed during our first event. After re-imaging it in safe-mode, we were able to get it up and running...

The trick to using Java: Image the cRio and select the Format Controller with a LabView image. Then image it again as Java without the Format Controller option selected.

Since then, everything has been flawless.

[Arhowk]

Originally Posted by Patrick Chiang

+ Vision. LV is better for vision development hands down. The fastest way to develop vision code in Java is to do it in NI's software, then copy the filters back into Java. The simplicity of it all is really one of the best unmatched feature LV has over Java.

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

Originally Posted by MrRoboSteve

I usually recommend to teams that they use the language that is most familiar to their programming mentor.

As an aside, Labview is widely used in industry, it's not just a FIRST thing. A quick look at dice.com indicates they have >100 jobs listed with Labview as a keyword.

That is a great example. Just look below the search box

Search job title only (e.g. Java Developer)

100 jobs for labview, 16000 for java. With this ratio, for every team using LV there should be 160 teams using Java to balance the market demands.

Originally Posted by Pi3th0n

Team 900 is (almost) unanimously in favor of Labview. We used Java last year and had all kinds of trouble with getting the robot to actually move. We switched to Labview this year and our robot runs beautifully. Also, most of our programmers this year didn't have any experience with either language before the start of the year and they picked up Labview really quickly.

Of course, the number of programmers on the team at least tripled from last year to this year, so that could make a difference too...

This is probably the only scenario where Labview is good, you have a bunch of people inexperienced with code and just were inspired to write code because of the god tablets slid into their pockets, though Patrick does make a good point

I've heard that LV is more intuitive for EE people with its resemblance to circuit diagrams.

Also, our team leader worked as a CSA at our 2nd district this year and noticed an enormous amount of teams (even rookies) using Java compared to last year.

[Joe Ross]

Originally Posted by Arhowk

This only applies for programmers who are inexperienced with computer vision. If you have two programmers with, lets say 3-4 years of experience in java and labview independently, the Java built (if we had a third using C++ he'd trump them all) will be faster and more percise. Note that in WPILibJ, some vision functions were missing and need to be wrapped

Why do you say that?