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

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

[mathking]

Almost every time I get in to a discussion about which language to use for FRC, someone starts talking about which language will yield faster programs. And the truth is that, compiled on to the cRIO there is not a "this language is faster than that language" rule.

It is true that in general if you write a program to run on your computer that a C++ application will run faster than a Java application. (Even this is a general principle and not a rule.) Because the Java application is compiled to Java byte code and run on the JVM. But when you compile Java into an application to run on a specific platform this is no longer a general principle. For example, I once used xCode to write some simple OS X native applications. I wrote the same applications in C++ and compiled them into OS X native applications. And which version was faster depended on what exactly I was doing.

For example, LabView is really good for integrating sensors and C++ is not natively friendly to event driven programming so the code is often not as natural to develop. Language choices always have tradeoffs, and it is more the exception than the rule that there is a clear "best" choice absent other constraints. If someone tells you that they use C++ (or any of the other choices) because "it is an industry standard" or "because it is faster" or my favorite "because it is better" (rather than "because it is better at a and b, which we do a lot") they probably have not made a well-informed decision.

A friend with a lot of C++ and LabView experience, who has programmed in Java quite a bit the last few years said that he would pick based on what the programming team has experience with. But absent that, he would say the more sensors you have, the more it makes sense to use LabView. He also said the bigger the overall code base, the more it makes sense to use C++ or Java. And in spite of his vast experience with C++ he nudged his team toward Java.

My own programming experience started with Fortran punch cards, then typed Fortran. Then I moved to Apple I Basic. At one point I was writing C and C++ large number processing algorithms for sensors and communication systems. I have used assembly. I also ventured into Pascal for while. I have taught C++ and Java. The past couple of years I have also taught MatLab. I used to be very resistant to OOP. I have come to believe that the larger the program, the stronger the case for OOP. I used to think that pointers we way better than the cumbersome structures used in Java. Then I started debugging big programs written in Java and I said "Wow, this takes a lot less time than it used to." I still use C for a lot of tasks. Lately I have seen a number of cool education-oriented tools with compiled Java (not the JVM) on machine level systems that run continuously and I think "The garbage collector alone is reason to use Java." I would be very willing to consider switching languages if we used RobotC (and its debugging tools). Again, my point is the same as a number of others. There is no best choice. Just make an informed choice and know that a well written program in any of the three language choices is probably going to run a lot better than a poorly written one in a supposedly better language.

[Patrick Chiang]

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

Not my experience. (And I know Java and C++ way more than LV.) Testing and debugging vision in Java or C++ has been a pain. It's a visual thing, so it makes sense a visual language does it better. The real time debugging features are pretty convenient too.

Originally Posted by Phalanx

#1) Risk - Software stability.
79 Bugs found in C++, 32 still open.
68 Bugs found in JAVA, 21 still open.
24 Bugs found in Labview, 10 still open.

Here’s the link where I obtained that information:
http://firstforge.wpi.edu/sf/go/projects.wpilib/tracker
Hence, Labview is the more reliable and stable platform.

Comparing number of bugs reported on a single bug tracker is a pretty poor metric. It could be there are less people using LV, or maybe the opposite is true. It could be people using LV are reporting their bugs elsewhere. It could be because the Java and C++ bugs were solved 2 months ago but the people who develop for those libraries received the bug reports on another platform and didn't close them here.

The FIRST tracker may be "official", but I personally don't know anyone who uses it to report bugs. If anything, comparing the number of problem threads on Chief Delphi and replies would be a more comprehensive metric for which tool is more stable.

Originally Posted by Phalanx

#2) Interoperability
The hardware(CRIO) is designed and manufactured by NI as is Labview.
They are meant to and designed to work together seamlessly.
The JVM is by Oracle, FRC Java Library is a port by WPI, as is C++
(Do correct me if I'm mistaken on the port statement).
As such you now have 2 additional and different software vendors.
Do we all know the expression, too many cooks spoil the soup?
So if there is a bug where is it and who do you ask to correct it?
Is it my code? Is it the Library? Is it the JVM?, or is it the hardware?

Hint: It's not the library, it's not the JVM, and it's not the cRIO. In all my 5 or 6 years of using FRC Java, I have personally never had to solve a problem that had to do with the library or the JVM or the cRIO, and I've never had the library behave in a way that is illogical for me. For me and the majority of teams I've helped or talked to at competitions, the library is never the problem.

Does this mean that the library is bugless and completely stable? No, but it's a much smaller problem than people seem to be making it, to the point where it's not a concern for most teams that will be using the common functions of the library.

Originally Posted by Phalanx

My own personal summary.
1) National Instruments makes and supports the CRIO and it's Modules.
2) National Instruments makes and supports LabView.
So when something doesn't work as it should or as designed then you only have ONE company one vendor to go to for a solution.

I have had this very issue in my professional career with software and hardware products that are "supposed" to work together.
Here's how it usually goes.
Vendor A says it must be something with Vendor B's product.
Vendor B says it must be something with Vendor A's product.
Round and around it goes, until someone other(usually ME) than Vendor A or Vendor B clearly identify who's problem it really is.

So I'd rather have one vendor to point a finger at, that can't point it at anyone else except themselves.

I'm only sharing my thoughts, my views, my experiences, the decisions are ultimately up to your team.

Here's the thing though: FRC is designed to emulate real life engineering where knowing the vendors is important and you need to have fire drills on who to call if something fails, but for most teams, that's just not how it is.
The cRIOs, libraries, JVM...etc are all fairly reliable. The biggest points of failure are usually the wiring on your robot or the code that you wrote. Pointing fingers at vendors is much less helpful than being able to debug and solve your problem immediately, which I'll argue that text based languages are better for.

Originally Posted by wt200999

I would actually say that LabVIEW has a steeper learning curve than its text based counter parts in many ways. As in any langauge it is very easy to make bad LabVIEW code. It seems that a lot of people stop learning the language when they have some of the basics down, and we end up seeing massive VIs of untamed wires and flat sequences which become hard/impossible to debug and maintain.

You can have spaghetti code in any language. It's just more literal "spaghetti" in LV.
I wouldn't say it has a steeper learning curve. For a all the basic functionality on top of a robot (without fancy custom steering code, PID, or vision...etc), you can learn to program in LV before you learn why you should be setting the value of the jags to a double in Java or C++. Unless, of course, you already knew a text based language.

Originally Posted by wt200999

Knowing what functions you want and using Quick Drop I would imagine is close in speed to typing the name out in Java. Also the percent of time spent on actually writing code vs debugging is an important factor.

Not even close. Say we have a robot with 4 jags, and each need to be controlled by a separate joystick. Don't ask why, the team needs it done now. In Java, the project takes 5 seconds to create, I can write up the code required in 30 seconds (conservatively), deploy to the robot in 52 seconds, go get a soda, and be back before the LV project is even fully created.

Comparing the code production time, I'll assume you're fairly fast and don't make mistakes in LV. It takes you at least 2 blocks for each jag, open and set, then you need 2 blocks for each joystick, open and set, then for each you need to specify the port, module, and channel constants, and then wire them all together.
Then, copy and paste 4 times and change each constant. If the whole thing is in a while loop, you also need to clean the broken wires and then rewire each time. Even if each palette you need is already pinned on the side (or using quick drop), I have a hard time seeing anyone do all that in 30 seconds, not to mention LV sometimes needs to open up new files whenever you access new tiles for the first time.

Originally Posted by Greg McKaskle

I can imagine it, but that isn't really the same task. Procedural languages require you to name variables. Wires are not named. For loops and case statements are one drag for numerous lines of code. The editors are different. The languages are different.

Come on, now. There are things that are easier in LabVIEW (like debugging vision as you said), but for loops and case statements are not them. How much does it really take to create a for loop in text code? 2 seconds? Creating and hooking up the constant true/false conditional in LV takes more time, and finding the comparison operator in LV takes time too.
Imagine if you had to do a perfectly reasonable conditional like (a && (b || c) && (d < e + f * g)), the race is over for LV at that point.

[Alan Anderson]

I wasn't going to enter the discussion about speed of development, but that last comment compels me.

Originally Posted by Patrick Chiang

Imagine if you had to do a perfectly reasonable conditional like (a && (b || c) && (d < e + f * g)), the race is over for LV at that point.

First off, I'd hardly call that a reasonable conditional. But even so, you're totally ignoring the fact that LabVIEW wouldn't have those variables in the first place. The Java code that would have set them prior to evaluating the condition has no counterpart in a LabVIEW program.

“Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid.”
― Albert Einstein

Doing something in a way that Java makes easy will obviously favor doing it in Java. On the other hand, doing it in a way that LabVIEW makes easy favors LabVIEW, and so on.

[mathking]

Originally Posted by Alan Anderson

Doing something in a way that Java makes easy will obviously favor doing it in Java. On the other hand, doing it in a way that LabVIEW makes easy favors LabVIEW, and so on.

Thank you Alan. This is something I strive mightily (and still often fail) to convey to students. My old boss used to struggle to convey it to developers.

[Greg McKaskle]

The 2013 project creation wizard was indeed slow. But the 2014 one is much faster, taking two seconds once I entered the IP address. Wow think what you can do with those extra three seconds.

As for how long it takes to create a for loop. I timed myself. Yeah, I know, it is sorta silly, but I do this thing for a living.

for(i=0;i<10;i++){
}

Takes me about nine seconds with no mistakes. Maybe I'm slow -- I balanced my own parenthesis and curlys after all.

The same code in LV without a pinned palette took under eight seconds.

But I'm sure that there is a way to configure emacs so that three meta key smashes and boom -- all done.

Anyway, this is getting silly even for me. Writing code is more than typing or drawing. LV is graphical because it cuts down on syntactical errors. LV has also supported algebraic syntax since version 1.0. It is called the formula node, and it is in the structure palette. The attached image shows the equivalent loop and formula.

By the way, this reminds me of the geekiest race I've ever observed. I was in college, working for the nuclear engineering department. Two grad students were poking fun at one another's choice of tool for formatting equations within their thesis. So how do two gentlemen end this dispute? With a race of course.

A neutral grad student found a gnarly fluid dynamics or neutron transfer equation that took up half a page in the textbook. He placed the books next to each participant and they were off. One was typing LaTex script, the other was using a graphical formula editor in MS Word. It took each of them several minutes, and they finished in a dead tie. It was like an episode of Big Bang, but I was there.

Anyway, have fun and good luck with whatever language you choose. It is of course fun to argue and compare, but don't let that get in the way of your robot tasks.

Greg McKaskle