Recently, me and my rookie have discussed about what language program would be best for our current programming part LabView or Java, our robot is still simple and we don’t have such ideia of which one could be best for us. So, you, who is more advanced in this FRC area, could you give us an explanation of what language is better and why?
BTW: Our program team started working with Labview and already have a bit understanding of it. Also, if Java > Labview, would it worth if we imigrate to Java?
The arguments for Java land as such:
Java is usually the better option if you don’t have precedent for using labview, as it’s easier to stand on the shoulders of giants and write the code that’s actually specific to your robot (as opposed to spending your precious time with the bot debugging your custom swerve kinematics). Beyond WPILib there’s tons of little libraries that make your life easier in Java, such as PathPlanner and photonlib.
Of course, deliberate carefully. Read through docs.wpilib.org and decide for yourself whether it is doable to switch this season or whether it should be tested in the off-season. I believe personally that Java is going to ultimately serve better for the FRC world, though. And keep in mind, if the students on the team are taking any CS classes in any language, that’s usually the best one to pick. There’s also an option for python (RobotPy).
With our team using LabView all of last year and just migrating to Java this year, I can say the speed of development is a lot faster for java with us. Java was a lot more familiar for new recruits than LabView and the documentation for Java and learning resources were a lot more plentiful as well.
Also when learning more intermediate and advanced topics such as swerve and trajectories, looks at other team’s Java code was a lot easier than looking at LabView code.
For context, that’s the percentage of FRC teams using each language each year as reported in usage reporting on the field. As you can see, Java is used by the vast majority of teams and usage is continuing to increase. That doesn’t mean you need to choose Java, just that you’ll benefit from more network effects (eg support online and at events from other teams) because a lot of other people are using it.
Not if @JSIMPSO has written them for you.
I feel old writing this. When I was a student, the only option I had was Labview. I spent a day just reading through the help files on all the different VIs. After that, I felt Labview was really nice, as all the I/O were in broad daylight, and the tools LV has are really good at explaining what needs to go in, and what will come out. I still hold this belief.
However, we use Java on my team now, and I see no reason to go back. WPILIB is very well documented - in fact, I spent a bunch of time yesterday reading through the functions in the library, similar to what I did with Labview back in the day.
If your team has experience with programming, and knows how to navigate a compiler, then you should be able to get what you need out of java.
If you’re all new to programming, and find yourselves as visual learners, then Labview may be a decent option as it is necessarily visual. That was my favorite thing about Labview.
Eventually someone will comment to you that Labview is slow and no one uses it in the real world. LV is indeed less optimized, but it has found a home in the 3 fortune 500 companies I’ve worked at, so it’s still a valuable language to learn if you have the resources. Having access to Labview now, and to be able to learn it is a pretty great opportunity.
Edit: for the record, LV may not have been the only option. java was not an option, and my mentor really liked Labview, and it was certainly really well documented for FIRST. My point still stands, and I still <3 LV
I’m more optimistic about the quality of an open-source library maintained by many active developers, than a port maintained by only one.
It’s a scale thing; the port is super impressive but using a library is as much about access to the ecosystem around it as it is the library itself.
As someone who used LabVIEW for four years as a student and has now assisted with programming five more robots with it as a mentor*, it’s difficult for me to recommend it if you don’t already have someone who knows it well. The basics can be easy to pick up, yes, but eventually you will come across something you can’t figure out on your own, and the community will struggle to help you. Additionally, there’s quite a few obscure convenience features in LabVIEW that really improve the FRC workflow that are difficult to find without a mentor. When I’ve helped other LabVIEW teams at events, I’m almost always learning they didn’t know of something I couldn’t imagine programming in LabVIEW without.
I think there’s absolutely a larger hump to get over with Java if you’re new to programming entirely - you can’t really get away without learning more of the basics - but once you do, you should be moving much faster with it.
*My students have also finally chosen Java over LabVIEW this year, so it seems those days are behind me. I’ll miss them a bit, but Java has been fun as well.
As far as the LabVIEW math library goes, the library has been tested quite extensively. I have also implemented the same test routines that that are used to test the Java/C++ routines. These tests run both on a PC and on the roboRIO. I do repeat that testing for any new release is made. If you do find an issue please report it on github.
I think it is important to allow the students to have the same tools for each of the supported languages.
I would be happy to see this library incorporated with the rest of the WPILIB so that all the supported FRC languages have the same tools and support.
As for me, I’ve programmed in more different languages than I care to count over the decades., including many many LabVIEW style languages currently in use to engineer industrial control systems. (Good control system engineers aren’t often good programmers.)
I’ve mentored teams under both Java and LabVIEW. I believe that the students should choose the language that helps them achieve their goals after fair open minded presentation of the advantages and disadvantages of each tool. We have started doing this discussion every year or two so they can choose. I can make a good case for either language based on the needs and capabilities of the team. Some of the strong points for LabVIEW include quick learning, very fast control system development (especially now with the library), concentration on the control engineering rather than the language. These of course apply differently to teams with different backgrounds. I do NOT want to start war about languages!!! So please, no responses…
Happy roboting to all
A good place to start would probably be to add the documentation to frc docs. If you opened a pull request adding a LabView section, I doubt it’d be turned down. You may have to justify yourself in the review process, but that’s ordinary for open-source contributions.
In modern FRC, I think the network effects swamp everything else and Java is the clear choice for beginning teams. LabView is a useful tool with a valid purpose, but the environment is not super favorable for it at the moment - resources are stretched thin and the language does not lend itself easily to remote collaboration over primarily text-based channels.
Cool graphics! I can visually see how the use of the language is really structured in the community. I’ll use that. Where did you get it from?
@calcmogul puts these together from the annual usage stats iirc. I plucked it from discord chat history.
Another shout out for the great work by @JSIMPSO. Our team were rookies last year and were looking at Java vs C++ vs LabVIEW. We ended up using LabVIEW because A) I used it in a former life and B) because the students actually found it easier to understand and modify than Java. I added a couple days of LabVIEW coding with Arduinos in my engineering class to help get the new guys up the curve. A number of students had already used the Arduino IDE w/ C from the previous year, and commented that they really enjoyed LabVIEW’s virtual instrument paradigm which let them be creative in laying out their UIs.
This year, we built our own swerve modules and I helped the team develop clean-sheet LabVIEW code to run them. I was delighted when I saw Jim’s announcement and turned our coders loose. They integrated his path generation stuff in just a couple days and are hard at work tweaking our Auton now.
I won’t dispute the benefits of a large community of developers, but I do think LabVIEW is a viable alternative to Java.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
