Thread: Java vs Labview
View Single Post
  #28   Spotlight this post!  
Unread 25-03-2014, 09:28
mathking's Avatar
mathking mathking is offline
Coach/Faculty Advisor
AKA: Greg King
FRC #1014 (Dublin Robotics aka "Bad Robots")
Team Role: Teacher
 
Join Date: Jan 2005
Rookie Year: 1999
Location: Columbus, OH
Posts: 638
mathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond reputemathking has a reputation beyond repute
Re: Java vs Labview

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.
__________________
Thank you Bad Robots for giving me the chance to coach this team.
Rookie All-Star Award: 2003 Buckeye
Engineering Inspiration Award: 2004 Pittsburgh, 2014 Crossroads
Chairman's Award: 2005 Pittsburgh, 2009 Buckeye, 2012 Queen City
Team Spirit Award: 2007 Buckeye, 2015 Queen City
Woodie Flowers Award: 2009 Buckeye
Dean's List Finalists: Phil Aufdencamp (2010), Lindsey Fox (2011), Kyle Torrico (2011), Alix Bernier (2013), Deepthi Thumuluri (2015)
Gracious Professionalism Award: 2013 Buckeye
Innovation in Controls Award: 2015 Pittsburgh
Event Finalists: 2012 CORI, 2016 Buckeye

Last edited by mathking : 25-03-2014 at 09:40.